# Tibi Docs und Demo Projekt

Diese Repo enthält die Dokumentation zum TibiCMS und eine Demo-Projekt welches die Dokumentation begleitet und als Projetstarter fungiert.

## neues Projekt - Checkliste

-   [x] neues Projekt im gitbase.de anlegen (cms/tibi_starter) als Vorlage verwenden
-   [ ] klonen
-   [ ] bereinigen

```sh
git filter-branch -f --index-filter 'git rm -rf --cached --ignore-unmatch .yarn/cache' HEAD
git filter-branch -f --index-filter 'git rm -rf --cached --ignore-unmatch docs' HEAD
git push --force
```

-   [ ] anpassen

    -   `.env`
    -   `docker-compose-local.yml` -> `TIBI_API_NAMESPACE: & PROJECT_NAME`
    -   `.gitea/workflows/deploy.yaml` -> `name:`
    -   `./api/hooks/config.js` -> `name:`
    -   `api/...`

-   [ ] upgraden

```sh
mkdir tmp
# evtl. zuvor: yarn install
make yarn-upgrade
make docker-pull

# falls Fehler auftreten, evtl. Berechtigungen fixen
make fix-permissions
```

-   [ ] los programmieren

```sh
make docker-start

# bei erstem fehlerhaften Start, evtl. Berechtigungen fixen:
make fix-permissions
```

-   [ ] Projekt in Tibi bekannt machen:
    -   <https://PROJEKTNAME-tibiadmin.code.testversion.online>
    -   Pfad der API-Konfig: `/data/api/config.yml`
-   [ ] Website im Browser ansehen:
    -   <https://PROJEKTNAME.code.testversion.online>
-   [ ] Testmails checken:

    -   <https://PROJEKTNAME-maildev.testversion.online>

-   [ ] deploy
    1. [ ] Subdomain im basispanel anlegen auf `../frontend/`
    2. [ ] rsync-Account in basispanel anlegen auf `htdocs/`
    3. [ ] Passwort in Secrets eintragen: <https://drone.gitbase.de>
    4. [ ] `deploy.yaml` deploy rsync user anpassen
    5. [ ] pushen

## SSR Aktivierung

Per se ist alles vorbereitet damit SSR aktiviert werden kann, hier muss nur START_SCRIPT=:ssr in der .env datei einkommentiert werden.
Es ist jedoch anzunehmen, dass während der entwicklung Dinge eingebaut wurden, dass die kompilierung schief geht. Um dies zu kontrollieren, muss man zunächst prüfen, ob Einträge in der SSR collection vorhanden sind. Gibt es keine Einträge, sollte man in die "/" Anfrage in den Netzwerkeinstellungen schauen. Hier ist in der Server Antwort im HTML template ein fehler zum debuggen zu finden!

# Git prozess - WICHTIG!

Der git Ablauf wurde mittels eines pre push Hooks modifiziert. Hier wird der aktuelle gepushte commit modifiziert, indem ein mongodump der aktuellen datenbank vor genommen wird und die kopie in ".gitea/actions/init-db/mongo-dump" abgespeichert wird.
Der pre-push hook liegt in .git und sieht wie folgt aus:

```sh
#!/bin/bash

ENV_FILE="$(git rev-parse --show-toplevel)/.env"
echo "PRE-PUSH HOOK: Running mongodump and adding it to the commit..."
# Check if the .env file exists
if [ ! -f "$ENV_FILE" ]; then
    echo ".env file not found. Push cancelled."
    exit 1
fi

# Source the .env file
source "$ENV_FILE"

# Name of the Docker container running MongoDB
CONTAINER_NAME="${PROJECT_NAME}-mongo-1"

# Directory to store the mongodump
OUTPUT_DIR=".gitea/actions/init-db/mongo-dump"
DUMP_DIR_NAME="tmp/mongo-dump"

# Message to append to the commit
APPEND_MSG="made a mongodump on current local database for tests to have data"

# Check if the container is running
if ! docker ps | grep -q "$CONTAINER_NAME"; then
    echo "MongoDB container '$CONTAINER_NAME' is not running. Push cancelled."
    exit 1
fi

# Perform mongodump
docker exec "$CONTAINER_NAME" mongodump --out /$DUMP_DIR_NAME && \
docker cp "$CONTAINER_NAME":/$DUMP_DIR_NAME "$OUTPUT_DIR"

# Check for successful mongodump
if [ $? -ne 0 ]; then
    echo "Mongodump failed. Push cancelled. Make sure that the mongo container is up and running, necessary for the Workflow, because it needs a seeded database, wich needs a mongodump beforehand."
    exit 1
fi

# Add the output to the current commit
git add "$OUTPUT_DIR"

# Amend the commit with a modified message
CURRENT_MSG=$(git log -1 --pretty=%B)
NEW_MSG="$CURRENT_MSG $APPEND_MSG"
git commit -m "$NEW_MSG"

# Continue with the push
exit 0
```

Diese Kopie wird gebraucht, um im Workflow unsere Lokale entwicklungsumgebung zu booten. Dieser workflow ist unter dem Namen lighthouse-evaluation in der deploy.yaml Datei zu finden. Es ist anzumerken, dass der Code funktioniert, er wurde in github getestet, jedoch in gitea das feature der Services noch nicht funktionsfähig ist, da Stand Februar 2024 das noch nicht unterstützt wird! Es wird jedoch sehr hilfreich sein, da
a) bei jedem Push eine lighthouse analyse durchgeführt wird und das Ergebnis davon in nextcloud hochgeladen wird. Bei bedarf kann natürlich auch die Funktion hinzugefügt werden, dass das Ergebnis direkt an seine Email gesandt wird oder ähnliches.
b) Man kann die Umgebung auch für Test zwecke verwenden. Wenn man also bspw. Cypress einbaut, so hat man direkt eine Umgebung um dies laufen zu lassen.