Files

125 lines
6.1 KiB
Markdown
Raw Permalink Normal View History

# Repository „Projektwissen" auf Gitea einrichten
Prüfliste für den Maintainer. Stand 04.09.2026. Einmalig auszuführen; danach ist dieses Dokument nur noch
Nachweis, was wie eingestellt wurde.
Alles hier ist **Menschenarbeit**. Ein KI-Agent kann die Texte vorbereiten, aber weder Repositories anlegen noch
pushen noch Schutzregeln setzen (ADR 0007).
## 1. Repository anlegen
Gitea → Organisation `AG_QGIS` → **Neues Repository**.
| Einstellung | Wert |
|---|---|
| Name | `Projektwissen` |
| Beschreibung | Gemeinsame Wissensbasis, Regeln und Werkzeuge der QGIS-Plugin-Entwicklung LNO Sachsen |
| Sichtbarkeit | öffentlich (wie die übrigen Repos der Organisation) |
| `.gitignore`, Lizenz, README | **nicht** anlegen lassen — bringt der erste Push mit |
| Issues | an |
| Wiki | aus — die Doku liegt versioniert im Repo (ADR-Begründung in `docs/wissen/externe_dienste.md`) |
| Standard-Branch | **`unstable`** – dort wird gearbeitet. Nicht `stable` (dann landet jeder Klon auf dem Releasestand) und nicht `main` (gibt es in diesem Modell nicht). Alle acht Code-Repos der Organisation stehen auf `unstable`; `main` haben nur `Defaults`, `Linkliste` und `Repository`, die kein Kanalmodell kennen. |
## 2. Ersten Stand pushen
Der Ordner `AG_QGIS/` ist bereits als Git-Repository vorbereitet, mit einem Commit, der genau die Dateien
dieses Repositories enthält (die Plugin-Klone sind per `.gitignore` ausgenommen).
```bash
cd <…>/AG_QGIS
git status # erwartet: nichts Unversioniertes außer den Plugin-Klonen
git log --oneline # erwartet: der vorbereitete erste Commit
git remote add origin https://entwicklung.flurneuordnung-sachsen.de/AG_QGIS/Projektwissen.git
git push -u origin unstable
```
Wir beginnen bewusst auf `unstable`, damit auch dieses Repository dem Kanal-Modell aus
[`../leitfaden/05_git_arbeitsweise.md`](../leitfaden/05_git_arbeitsweise.md) folgt.
**Vor dem Push prüfen:**
- [ ] **Autor des Commits stimmt.** `git log -1 --format='%an <%ae>'` – erwartet wird die Adresse des
Gitea-Kontos, weil Gitea Commits darüber dem Benutzer zuordnet. Stimmt sie nicht, vor dem Push korrigieren:
```bash
git config user.name "Vorname Nachname"
git config user.email "vorname.nachname@lfulg.sachsen.de"
git commit --amend --reset-author --no-edit
```
- [ ] `git status` zeigt keine Plugin-Ordner (`Plugin_SN_*`, `Repository`, `Linkliste`, `Defaults`)
- [ ] `entwuerfe/` ist nicht enthalten
- [ ] keine Zugangsdaten, keine Tokens, keine echten Verfahrensdaten
- [ ] `python scripts/run_tests.py` läuft
- [ ] `python scripts/testkatalog.py --pruefen` meldet „aktuell"
## 3. Branches anlegen
```bash
git switch -c testing unstable && git push -u origin testing
git switch -c stable unstable && git push -u origin stable
git switch unstable
```
Danach in Gitea unter **Einstellungen → Allgemein** prüfen, dass der Standard-Branch weiterhin `unstable` ist —
das Anlegen weiterer Branches ändert ihn zwar nicht, aber es kostet nichts, einmal hinzusehen.
## 4. Branch-Schutz setzen
**Einstellungen → Branches** (englisch: *Settings → Branches*), dort eine neue Branch-Schutzregel anlegen — je
einmal für `stable`, `testing` und `unstable`:
| Einstellung | Wert |
|---|---|
| Branch-Name | `stable` / `testing` / `unstable` |
| Push deaktivieren | an |
| Merge-Freigabe erforderlich | mindestens 1 |
| Veraltete Freigaben verwerfen | an |
| Statusprüfungen erforderlich | erst aktivieren, wenn CI läuft (Abschnitt 6) |
## 5. Dasselbe für die Plugin-Repositories
Dort fehlt bisher der stabile Kanal. Je Repo (`Plugin_SN_Basis`, `Plugin_SN_Plan41`,
`Plugin_SN_Verfahrensgebiet`, `Plugin_SN_Widmung`, `Plugin_SN_FLT`, `Plugin_SN_Topografie`,
`Plugin_SN_Template`):
- [ ] `stable` anlegen — aus `testing`, wo es das gibt, sonst aus `unstable`. **Der Name muss exakt `stable`
lauten**, weil der Release-Workflow `git checkout "$CHANNEL"` ausführt (ADR 0007).
- [ ] Branch-Schutz für `stable`, `testing`, `unstable` wie in Abschnitt 4
- [ ] `oldstable` prüfen (`Plugin_SN_Basis`, `Plugin_SN_Plan41`): enthält er noch etwas Nötiges? Sonst löschen.
- [ ] Verwaiste Branches prüfen und löschen: `feature/Drucklayout-überarbeiten`, `print_layout` (Basis),
`bug/crash_on_exit` (Plan41), `alkis-nur-laden-stop`, `fix-fbschl-feldname` (Verfahrensgebiet)
Erst danach funktioniert ein Release auf dem stabilen Kanal (Tag ohne Suffix).
## 6. Optional: Tests in CI
Vorlage: [`../vorlagen/gitea_workflow_tests.yaml`](../vorlagen/gitea_workflow_tests.yaml) → als
`.gitea/workflows/tests.yaml` in `Plugin_SN_Basis`, `Plugin_SN_Plan41` und `Plugin_SN_Verfahrensgebiet`.
Sie klont das Projektwissen und die Nachbar-Repos und führt den Baseline-Lauf aus.
Voraussetzung: ein Gitea-Runner mit dem Label `alpine-latest` (wie beim Release-Workflow). Läuft das, in
Abschnitt 4 „Statusprüfungen erforderlich" aktivieren.
Der Ausbau zu Tests gegen echtes QGIS steht in
[`07_qgis_tests_plan.md`](07_qgis_tests_plan.md) und braucht einen Runner mit Docker.
## 7. Team informieren
- [ ] Link zum Repository und zur [`README.md`](../../README.md) verteilen
- [ ] Auf die Umstellung hinweisen: der Klon-Befehl heißt jetzt
`git clone .../Projektwissen.git AG_QGIS` (Ordnername unverändert)
- [ ] Um Durchsicht der Entscheidungen 0006–0009 bitten; nach Zustimmung den Status aller ADR von
„vorgeschlagen" auf „angenommen" setzen
- [ ] Jede Person trägt sich in `docs/status/STATUS.md` unter „Wer arbeitet woran" ein
## 8. Nach der Einrichtung zu klären
Diese Punkte liegen als Entwürfe bzw. offene Baustellen in `docs/status/STATUS.md`:
1. **QGIS-Mindestversion.** Steht auf 3.40, das seit Januar 2026 End of Life ist
([`07_qgis_tests_plan.md`](07_qgis_tests_plan.md) Abschnitt 2). Betrifft `workspace.toml` und alle
`.gitea/templates/metadata.template`.
2. **`.vscode/` aus den Plugin-Repos entfernen.** Liegt in vier Repos mit fest verdrahteten Pfaden eines
einzelnen Arbeitsplatzes. Je ein kleiner Pull Request.
3. **Release-Excludes ergänzen** (`Repository:hidden/workflows`): `AGENTS.md`, `CLAUDE.md`, `.agents/`,
`.claude/`, `docs/`, `tests/`, `.vscode/`.