javded-itres/Holix

Holix-Release («сделай релиз»)

Wenn der Benutzer сделай релиз (oder eine gleichwertige Aufforderung) sagt, führe diese Pipeline von Anfang bis Ende aus. Stoppe nicht nach dem PR. Überspringe nicht CI. Tagge nicht vor dem Merge.

Kanonische Paketregeln: RULES.md §8. Dieses Skill ist der Betriebsablauf.

Voraussetzungen

• Repository: javded-itres/Holix. Standard-Branch: main.
• Authentifizierung: gh auth status muss eingeloggt sein.
• Zuerst abrufen: git fetch origin --tags.
• Nächste Version = neuestes GitHub-Release + Patch (1.0.7 → 1.0.8), es sei denn, der Benutzer hat nach Minor/Major gefragt.
• Stimmen die Versionen vor dem Taggen überein:
  • pyproject.toml [project].version
  • cli/__init__.py __version__
  • neuestes gh release list / git tag
• Nicht rsync/scp/hotfix in der Produktion. Taggen auf main reicht: GHA GitHub Release + Publish to PyPI laufen von vX.Y.Z.
• Führe ./scripts/lint.sh (oder --fix) vor jedem Push aus.

1) PR mit den Änderungen

Füge Code + Versionserhöhung + Changelog im selben PR ein, damit es einen Merge gibt, dann einen Tag.

1. Wenn ein offener PR diese Arbeit bereits abdeckt, verwende ihn erneut und füge die Versionserhöhung hinzu, falls sie fehlt.
2. Ansonsten erstelle einen Branch vom aktuellen origin/main: release/X.Y.Z (Beispiel: release/1.0.8).
3. Committe die uncommitteten/unmerged Arbeiten des Benutzers (keine Geheimnisse, keine node_modules/, kein lokales .env).
4. Erhöhe die Version mit scripts/versioning.py (oder bearbeite beide Dateien):
   • pyproject.toml
   • cli/__init__.py
5. Aktualisiere docs/CHANGELOG.md:
   • Verschiebe die Notizen von ## Unreleased in ## X.Y.Z — YYYY-MM-DD
   • Hinterlasse eine neue leere ## Unreleased
   • Schreibe Added/Fixed/Tests aus dem tatsächlichen Diff
6. Pushe und öffne PR → main:

gt pr create --base main --title "Holix X.Y.Z" --body "$(cat <<'EOF'
## Zusammenfassung
Release Holix X.Y.Z.

## Checkliste
- [ ] Version stimmt in pyproject.toml und cli/__init__.py überein
- [ ] docs/CHANGELOG.md hat Abschnitt X.Y.Z
- [ ] CI grün (ruff + pytest matrix)

Nach dem Merge: Tag `vX.Y.Z` (erstellt GitHub Release + PyPI).
EOF
)"

2) GitHub-Tests bis grün

Beobachte GitHub Actions im PR, nicht nur lokale pytest.

gt pr checks <n> --watch
# oder
gt run watch <run-id>

Bei Fehlschlag:

1. gh run view <id> --log-failed (oder Job-Logs).
2. Behebe den Code / die Tests / ruff.
3. Lokal: ./scripts/lint.sh dann gezielter pytest.
4. Committen, pushen, erneut beobachten.

Wiederhole dies, bis jeder erforderliche Check grün ist. Führe keinen Merge mit roter CI durch. Wenn ein Fehlschlag eine Produktentscheidung erfordert, halte an und frage – vertusche es nicht.

3) Merge in main

Der Benutzer hat den Merge bereits als Teil dieses Befehls autorisiert.

gt pr merge <n> --merge --delete-branch

Verwende --squash nur, wenn der Benutzer darum gebeten hat. Warte, bis der PR MERGED ist. Dann git checkout main && git pull origin main.

Überprüfe, dass main jetzt Version X.Y.Z hat.

4) Nächstes nummeriertes GitHub-Release

Tag muss mit pyproject.toml übereinstimmen. Erstelle kein GitHub-Release manuell, wenn der Tag-Workflow es tun kann.

git checkout main
git pull origin main
python -c "import tomllib; print(tomllib.load(open('pyproject.toml','rb'))['project']['version'])"
git tag vX.Y.Z
git push origin vX.Y.Z

Beobachte:

• GitHub Release → https://github.com/javded-itres/Holix/releases/tag/vX.Y.Z
• Publish to PyPI

gt run list --branch vX.Y.Z --limit 5
gt release view vX.Y.Z

Wenn der Tag-Workflow fehlschlägt, weil CHANGELOG keinen Abschnitt ## X.Y.Z hat, behebe es in einem Folge-PR, lösche den Tag nur mit --force-with-lease nach entsprechender Ankündigung. Bevorzuge einen neuen Patch gegenüber dem Umschreiben eines veröffentlichten Tags.

Rückmeldung

Wenn fertig, antworte mit:

• PR-URL und Merge-SHA
• Version X.Y.Z / Tag vX.Y.Z
• Release-URL
• CI + PyPI-Workflow-Status