dg/claude-skills
1
0 Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 20 Wiki Activity

Clean docs of host-specific release and contact details.

Browse Source 
Describe releases generically and use the same git credentials as push.
This commit is contained in:
Dominic Gundel committed 2026-10-19 16:18:05 +02:00
1 parent 2c02038e8c
commit 7d71ae8dde
7 files changed
+56 -64
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

CONTRIBUTING.md
+9 -33
View File
@@ -55,7 +55,7 @@ skills/<name>/
git push origin main <name>/v<version>
```
7. Release vom eigenen Rechner anlegen (siehe unten). Auf git.gundel.dev läuft kein Actions-Runner.
7. Release anlegen (siehe unten): Pakete bauen und dem Tag als Anhänge hinzufügen.
## Update eines Skills
@@ -91,50 +91,26 @@ powershell -ExecutionPolicy Bypass -File scripts\package-mcpb.ps1 -Name <name>
powershell -ExecutionPolicy Bypass -File scripts\package-all.ps1
```
### Vom eigenen Rechner
### Release veröffentlichen
Auf git.gundel.dev ist kein Actions-Runner registriert. Das Release legt deshalb ein Skript auf dem Rechner an, der das ZIP schon gebaut hat. Es spricht die Gitea-API an ([Release anlegen](https://docs.gitea.com/enterprise/api/21/operations/repo-create-release/), [Anhang hochladen](https://docs.gitea.com/api/operations/repo-create-release-attachment/)):
Der Tag `<name>/v<version>` muss lokal und remote existieren. Danach entweder:
- `POST /api/v1/repos/dg/claude-skills/releases`
- `POST /api/v1/repos/dg/claude-skills/releases/{id}/assets`
Dafür braucht es ein persönliches Zugangs-Token mit Schreibrecht auf dieses Repository (`write:repository`). Anlegen unter Profil → Einstellungen → Applications. Authentifizierung: [`Authorization: token …`](https://docs.gitea.com/development/api-usage/). Das Token nur in die Umgebung legen, nicht ins Repository.
Der Tag `<name>/v<version>` muss lokal existieren und schon auf dem Server liegen. Das Skript verschiebt keine Tags und pusht nichts.
**Skript** (baut ZIP/`.mcpb` und hängt sie ans Release; nutzt dieselbe Anmeldung wie `git push`):
```powershell
$env:GITEA_TOKEN = '<Token>'
powershell -ExecutionPolicy Bypass -File scripts\release.ps1 -Name <name>
```
```sh
GITEA_TOKEN='<Token>' scripts/release.sh <name>
scripts/release.sh <name>
```
### Manuell, ohne Token
**Oder manuell** in der Release-Oberfläche des Remotes:
1. Paket bauen (Befehle oben). Prüfen, dass `dist/<name>-v<version>.zip` die Einträge `<name>/` und `<name>/SKILL.md` enthält und weder `README.md` noch `CHANGELOG.md`.
2. Unter [Releases](https://git.gundel.dev/dg/claude-skills/releases) ein neues Release anlegen.
3. Tag: `<name>/v<version>` (der Tag muss schon auf dem Server liegen). Titel: `<name> <version>`.
4. Als Text den Abschnitt dieser Version aus `skills/<name>/CHANGELOG.md` einfügen.
5. `dist/<name>-v<version>.zip` als Anhang hochladen.
6. Falls vorhanden: `dist/<name>-v<version>.mcpb` ebenfalls hochladen (oder `scripts/release.ps1` nutzen – hängt beides an).
Nur die `.mcpb` nachträglich an ein bestehendes Release hängen (Token nur in der Umgebung):
```powershell
$env:GITEA_TOKEN = '<Token>'
$id = <Release-ID>
$name = 'wordcraft-mcp-v0.2.0.mcpb'
$bytes = [IO.File]::ReadAllBytes("dist\$name")
$req = [Net.HttpWebRequest]::Create("https://git.gundel.dev/api/v1/repos/dg/claude-skills/releases/$id/assets?name=$name")
$req.Method = 'POST'
$req.Headers.Add('Authorization', "token $env:GITEA_TOKEN")
$req.ContentType = 'application/octet-stream'
$req.ContentLength = $bytes.LongLength
$s = $req.GetRequestStream(); $s.Write($bytes, 0, $bytes.Length); $s.Close()
$resp = $req.GetResponse(); (New-Object IO.StreamReader($resp.GetResponseStream())).ReadToEnd()
```
2. Neues Release zum Tag `<name>/v<version>` anlegen, Titel `<name> <version>`.
3. Als Text den Abschnitt dieser Version aus `skills/<name>/CHANGELOG.md` einfügen.
4. `dist/<name>-v<version>.zip` und – falls vorhanden – `dist/<name>-v<version>.mcpb` anhängen.
## Hinweise zu den Skripten