127 lines
4.7 KiB
Markdown
127 lines
4.7 KiB
Markdown
# 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.
|