Zum Inhalt

Mitwirken

Beiträge zu Rezepten, Launcher, Core und Doku sind willkommen. Bitte klein, testbar und ohne Secrets halten.

Entwicklungsumgebung

git clone https://github.com/benjarogit/rezeptor.git
cd rezeptor
# Distro (für Clone/tar.gz-Entwicklung): python-pyqt6, bats-core, shellcheck
pip install --user PyQt6-Fluent-Widgets   # optional
# Endnutzer auf Bazzite o.Ä.: Release-AppImage oder Flatpak — kein Host-PyQt6
make validate
make test
REZEPTOR_DEV=1 ./setup.sh

Doku lokal:

pip install -r requirements-docs.txt
mkdocs serve

Qualitätstor

Vor jedem PR:

make validate          # shellcheck, syntax, compile, i18n-check, ruff, recipes-check, recipe-lint, manifest
make test              # bats
make pytest            # Launcher-Unit-Tests (tests/*.py; braucht pytest + PyQt6)
./scripts/recipe-lint.sh
./scripts/recipe-manifest.sh   # nach Rezept-Dateiänderungen → commit

make validate → shellcheck prüft core/, recipes/photoshop, recipes/premiere, recipes/wiso-steuer, launcher/, scripts/.
bash -n (Target syntax) deckt alle recipes/*/*.sh ab; für andere Rezepte zusätzlich ./scripts/recipe-lint.sh.
i18n-check vergleicht Key-Sets von launcher/locales/de.json und en.json (make i18n-check).
ruff lintet launcher/ (make ruff; in CI zusätzlich astral-sh/ruff-action).
Optional: make dead-code (vulture, siehe requirements-dev.txt) — nicht Teil von validate; Whitelist unter scripts/vulture_whitelist.py.
Optional: make shell-dup-check — schlägt fehl, wenn Rezept-Hooks Funktionen aus core/ neu definieren; Allowlist: scripts/shell-dup-allowlist.txt.

Rezepte

  1. ./scripts/new-recipe.sh … oder GUI Neues Rezept…
  2. recipe.yml + Hooks gemäß Entwickler-Übersicht
  3. Mit echter Quelle testen (Install → Validate → Repair → Launch → Uninstall)
  4. Manifest aktualisieren
  5. Keine App-Binaries im Repo (BYOS)

Ideen: Recipe Submission.

Doku & Übersetzungen

  • Seiten spiegeln unter docs/de/ und docs/en/ (gleiche Dateinamen)
  • UI-Strings: Übersetzungen
  • Marke: BRAND — keine Purple-Themes

Git-Hinweise / PR-Workflow

main ist geschützt (GitHub Ruleset): kein Direct-Push, Änderungen nur per Pull Request. CI-Job validate muss grün sein, bevor gemergt werden darf. Review-Approvals sind nicht Pflicht (Solo-Maintainer ok).

git switch -c topic/kurzname
# … ändern, lokal: make validate && make test …
git push -u origin HEAD
gh pr create --fill   # oder mit Titel/Body
# CI abwarten → Merge (Squash oder Merge-Commit)
  • SemVer über Datei VERSION — nur bumpen, wenn ein Release beabsichtigt ist
  • Keine Co-Author-Trailer von Editor-Agenten in Commits
  • Keine Secrets (Tokens, private Installer) committen

Releases

  • SemVer in VERSION bumpen und per PR nach main mergen → GitHub Actions baut AppImage, Flatpak und tar.gz und veröffentlicht das Release
  • Assets: https://github.com/benjarogit/rezeptor/releases

Weiter