# Gitea für ASPICE 4.0 einrichten

Konkrete Anleitung für den slohmaier Dev Process auf Basis von Gitea, Doorstop und Gitea Actions.

## Gitea installieren

### Docker (empfohlen)

```yaml
# docker-compose.yml
version: "3"
services:
  gitea:
    image: gitea/gitea:latest
    ports:
      - "3000:3000"
      - "222:22"
    volumes:
      - ./data:/data
    environment:
      - USER_UID=1000
      - USER_GID=1000
```

```bash
docker compose up -d
```

### PlantUML-Rendering aktivieren

In `data/gitea/conf/app.ini`:

```ini
[markup.plantuml]
ENABLED         = true
NEED_POSTPROCESS= true
FILE_EXTENSIONS = .puml
RENDER_COMMAND  = plantuml -tsvg -pipe
IS_INPUT_FILE   = false
```

Oder über den öffentlichen Renderer (kein lokales PlantUML nötig):

```ini
[server]
OFFLINE_MODE = false

[markup.plantuml]
ENABLED = true
NEED_POSTPROCESS = true
RENDER_COMMAND   = curl -s https://www.plantuml.com/plantuml/svg/~h
```

## Organisations- und Repo-Struktur

```
Organisation: slohmaier          (eigene Projekte)
Organisation: kunde-projektname  (Kundenprojekte)
  Repo: projektname              (Monorepo: reqs + docs + src + tests)
```

Ein Repo pro Projekt. Kein Aufteilen in viele Repos.

## Label-Schema

Alle Labels in der Organisation anlegen, dann in jedem Repo verfügbar.

| Label | Farbe | Verwendung |
|-------|-------|------------|
| `type:requirement` | blau | Anforderungs-Issue |
| `type:architecture` | dunkelblau | Architektur-Entscheidung |
| `type:implementation` | grün | Implementierungsaufgabe |
| `type:test` | hellgrün | Testfall |
| `type:document` | grau | Dokument-Änderung |
| `aspice:NC` | rot | Non-Conformity |
| `aspice:change-request` | orange | Change Request |
| `aspice:finding` | gelb | QA-Finding |
| `status:review-required` | lila | Wartet auf Review |
| `status:approved` | grün | Freigegeben |
| `severity:critical` | dunkelrot | Kritisch |
| `severity:major` | orange | Schwerwiegend |
| `severity:minor` | gelb | Geringfügig |

## Branch-Schutz

Für `main`:
- Kein direktes Pushen
- Mind. 1 Approval erforderlich
- CI muss grün sein

Einstellbar unter: Repo → Settings → Branches → Branch Protection

## Branching-Strategie

```
main          protected, stabil, nur via PR
develop       Integrationsbranch
feature/SWE-001-can-init   Feature mit Req-Referenz
docs/qa-plan-v1           Dokument-Änderung
fix/NC-003-misra-violation Bugfix mit NC-Referenz
release/v1.0              Release-Branch
```

## PR/Review-Workflow

### Neue Anforderung anlegen
```
1. Branch: reqs/SWE-001-can-init
2. Datei anlegen: reqs/swe/SWE-001.md
3. PR erstellen mit Titel: "[REQ] SWE-001: CAN Bus Initialisierung"
4. Reviewer zuweisen
5. Nach Approval → Merge
```

### Dokument ändern
```
1. Branch: docs/qa-plan-update
2. Änderung in docs/QA-Plan.md
3. PR mit Beschreibung der Änderung
4. Reviewer zuweisen → Approval → Merge
```

### Code-Änderung
```
1. Branch: feature/SWE-001-can-init
2. Commit-Message: "feat(SWE-001): implement CAN bus init at configurable baudrate"
3. PR: "Refs #<issue-nummer>"
4. CI muss grün sein
5. Reviewer → Approval → Merge
```

## Commit-Message-Konvention

```
feat(SWE-001): implement CAN bus initialization
fix(NC-003): resolve MISRA Rule 14.4 violation
docs(QA-Plan): add review schedule for SWE phase
test(SWE-001): add unit test for CAN init error handling
```

Format: `<type>(<id>): <beschreibung>`

## Gitea Actions — Basis-Pipeline

```yaml
# .gitea/workflows/validate.yml
name: Validate
on: [push, pull_request]

jobs:
  validate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3

      - name: Install tools
        run: |
          pip install doorstop
          apt-get install -y cppcheck

      - name: Doorstop check
        run: doorstop check

      - name: MISRA check
        run: |
          cppcheck --addon=misra --error-exitcode=1 \
                   --suppress=misra-c2012-15.5 \
                   src/

      - name: Unit tests
        run: make test

      - name: Coverage
        run: make coverage

      - name: Publish traceability
        run: |
          doorstop publish all docs/traceability/
          git config user.email "ci@slohmaier.com"
          git config user.name "CI"
          git add docs/traceability/
          git diff --cached --quiet || git commit -m "ci: update traceability report"
          git push
```

## Doorstop konfigurieren

`.doorstop.yml` im Repo-Root:

```yaml
settings:
  digits: 3
  prefix: REQ
```

`.doorstop` in jedem Requirements-Unterordner:

```yaml
# reqs/sys/.doorstop
settings:
  digits: 3
  prefix: SYS
  parent: null
```

```yaml
# reqs/swe/.doorstop
settings:
  digits: 3
  prefix: SWE
  parent: SYS
```

```yaml
# tests/unit/.doorstop
settings:
  digits: 3
  prefix: TST
  parent: SWE
```

## VS Code Extensions für diesen Stack

| Extension | ID | Zweck |
|-----------|-----|-------|
| PlantUML | jnbt.plantuml | Diagramm-Preview in Markdown |
| Markdown All in One | yzhang.markdown-all-in-one | Markdown-Bearbeitung |
| YAML | redhat.vscode-yaml | YAML-Frontmatter in .md |
| GitLens | eamodio.gitlens | Git-History und Blame |
| Continue | Continue.continue | KI-Assistent lokal via Ollama |

## Traceability-Übersicht

```
SYS-001 (System-Anforderung)
  └── SWE-001 (Software-Anforderung)  [links: SYS-001]
        └── TST-001 (Testfall)         [links: SWE-001]
              └── Commit abc1234       [feat(SWE-001): ...]
                    └── PR #12         [Refs #5 (Issue: SWE-001)]
```

Doorstop prüft die komplette Kette automatisch bei jedem CI-Lauf.