AndreasTharang
c4cd2641ff
Gitea fragt den Standardbranch schon beim Anlegen ab, nicht erst beim ersten Push. Mit Begruendung und dem Abgleich zu den bestehenden Repos: acht Code-Repos stehen auf unstable, main nur die drei ohne Kanalmodell.
125 lines
6.1 KiB
Markdown
125 lines
6.1 KiB
Markdown
# 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/`.
|