Moves readmes to separate folder docs
This commit is contained in:
3 files changed
+32
-4
No files matched your search
@@ -0,0 +1,337 @@
|
||||
# Entwicklerhinweise: Anforderungen bei Push und Pull Request
|
||||
|
||||
Dieses Repository verwendet Jenkins-basierte PR- und Branch-Policies.
|
||||
Ziel ist, dass Code bereits **vor dem Merge** bestimmte Qualitätsanforderungen erfüllt.
|
||||
|
||||
Diese Datei beschreibt, **was bei einem Push erwartet wird**, **was in Jenkins geprüft wird** und **wie du Fehler lokal vermeiden kannst**.
|
||||
|
||||
---
|
||||
|
||||
## Überblick
|
||||
|
||||
Bei Pushes und Pull Requests werden automatisierte Policies ausgeführt.
|
||||
|
||||
Je nach Build-Typ gelten leicht unterschiedliche Vergleichsregeln:
|
||||
|
||||
- **bei Pull Requests** wird gegen den Zielbranch verglichen, z. B. `origin/main`
|
||||
- **bei normalen Branch-Builds** wird auf eine lokale Vergleichsbasis zurückgefallen, z. B. `HEAD~1`, falls kein Zielbranch-Ref verfügbar ist
|
||||
|
||||
Die eigentlichen Qualitätsanforderungen bleiben gleich.
|
||||
|
||||
---
|
||||
|
||||
## Was beim Push / PR geprüft wird
|
||||
|
||||
### 1. `.clang-format` muss vorhanden sein
|
||||
Im Repository-Root muss eine Datei `.clang-format` liegen.
|
||||
|
||||
Ohne diese Datei schlägt der Policy-Check fehl.
|
||||
|
||||
---
|
||||
|
||||
### 2. Geänderte C/C++-Dateien müssen korrekt formatiert sein
|
||||
Für geänderte C/C++-Dateien wird `clang-format` geprüft.
|
||||
|
||||
Betroffen sind insbesondere Dateien mit diesen Endungen:
|
||||
|
||||
- `.c`
|
||||
- `.cc`
|
||||
- `.cpp`
|
||||
- `.cxx`
|
||||
- `.h`
|
||||
- `.hh`
|
||||
- `.hpp`
|
||||
- `.hxx`
|
||||
|
||||
Wenn eine Datei nicht korrekt formatiert ist, schlägt der Build fehl.
|
||||
|
||||
#### Lokal prüfen
|
||||
```bash
|
||||
clang-format --dry-run --Werror <datei>
|
||||
```
|
||||
|
||||
#### Lokal automatisch formatieren
|
||||
```bash
|
||||
clang-format -i <datei>
|
||||
```
|
||||
|
||||
Beispiel:
|
||||
```bash
|
||||
clang-format -i main.cpp tests/test_main.cpp
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 3. Zu geänderten C/C++-Dateien muss ein passender Test existieren
|
||||
Wenn du eine C/C++-Datei änderst, muss ein passender Test vorhanden sein.
|
||||
|
||||
Es wird nach Tests in diesen Verzeichnissen gesucht:
|
||||
|
||||
- `tests/`
|
||||
- `test/`
|
||||
- `qt6-after/qt6-migrated-benchmark/tests/`
|
||||
|
||||
Unterstützte typische Testnamen sind zum Beispiel:
|
||||
|
||||
- `test_<name>.cpp`
|
||||
- `<name>_test.cpp`
|
||||
- `<name>test.cpp`
|
||||
- `<name>gtest.cpp`
|
||||
|
||||
Zusätzlich erkennt die Policy auch ähnliche Dateinamen heuristisch, solange `test` oder `gtest` im Dateinamen vorkommt.
|
||||
|
||||
#### Beispiel
|
||||
Wenn du `main.cpp` änderst, ist z. B. passend:
|
||||
|
||||
```text
|
||||
tests/test_main.cpp
|
||||
```
|
||||
|
||||
Wenn kein passender Test gefunden wird, schlägt der Build fehl.
|
||||
|
||||
---
|
||||
|
||||
### 4. Nur gültig SSH-signierte Commits sind erlaubt
|
||||
Neue Commits im geprüften Bereich müssen gültig **mit SSH signiert** sein.
|
||||
|
||||
Die Jenkins-Policy prüft Commit-Signaturen gegen eine erlaubte Signiererdatei:
|
||||
|
||||
```text
|
||||
ci/allowed_signers
|
||||
```
|
||||
|
||||
Wenn ein Commit:
|
||||
|
||||
- nicht signiert ist
|
||||
- nicht per SSH signiert ist
|
||||
- mit einem nicht erlaubten SSH-Schlüssel signiert ist
|
||||
|
||||
dann schlägt der Build fehl.
|
||||
|
||||
---
|
||||
|
||||
## SSH-signierte Commits einrichten
|
||||
|
||||
### 1. SSH-Signing-Key erzeugen
|
||||
Falls du noch keinen dedizierten Signing-Key hast:
|
||||
|
||||
```bash
|
||||
ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_signing -C "dein.name@example.com"
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 2. Git für SSH-Signing konfigurieren
|
||||
|
||||
```bash
|
||||
git config --global gpg.format ssh
|
||||
git config --global user.signingkey ~/.ssh/id_ed25519_signing.pub
|
||||
git config --global commit.gpgsign true
|
||||
```
|
||||
|
||||
Damit werden neue Commits automatisch mit deinem SSH-Key signiert.
|
||||
|
||||
---
|
||||
|
||||
### 3. Öffentlichen Schlüssel zur Allowlist hinzufügen
|
||||
Dein öffentlicher Schlüssel muss in `ci/allowed_signers` eingetragen sein.
|
||||
|
||||
Format:
|
||||
|
||||
```text
|
||||
<principal> <public-key>
|
||||
```
|
||||
|
||||
Beispiel:
|
||||
|
||||
```text
|
||||
max.mustermann@example.com ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA...
|
||||
```
|
||||
|
||||
Ohne Eintrag in `ci/allowed_signers` wird dein signierter Commit in Jenkins trotzdem abgelehnt.
|
||||
|
||||
---
|
||||
|
||||
### 4. Optional: lokale Verifikation aktivieren
|
||||
Wenn du lokal dieselbe Vertrauenskette wie Jenkins verwenden willst:
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.config/git
|
||||
cp ci/allowed_signers ~/.config/git/allowed_signers
|
||||
git config --global gpg.ssh.allowedSignersFile ~/.config/git/allowed_signers
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### 5. Signierten Commit erstellen
|
||||
```bash
|
||||
git add .
|
||||
git commit -S -m "Meine Änderung"
|
||||
git push
|
||||
```
|
||||
|
||||
Wenn `commit.gpgsign=true` gesetzt ist, signiert Git Commits in der Regel automatisch.
|
||||
|
||||
---
|
||||
|
||||
### 6. Signatur lokal prüfen
|
||||
```bash
|
||||
git log --show-signature -1
|
||||
git verify-commit HEAD
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Lokaler Minimal-Check vor dem Push
|
||||
|
||||
Vor dem Push solltest du mindestens diese Schritte ausführen:
|
||||
|
||||
### Format anwenden
|
||||
```bash
|
||||
clang-format -i main.cpp tests/test_main.cpp
|
||||
```
|
||||
|
||||
### Policy lokal ausführen
|
||||
```bash
|
||||
python3 ci/check_pr_policies.py
|
||||
```
|
||||
|
||||
## Projekt lokal im CI-Container bauen
|
||||
|
||||
Zuerst das lokale CI-Image bauen:
|
||||
|
||||
```bash
|
||||
docker build -t lifemaps/ci-cpp:latest -f Dockerfile.ci .
|
||||
```
|
||||
|
||||
Danach das Projekt im Container bauen und testen:
|
||||
|
||||
```bash
|
||||
docker run --rm -it \
|
||||
-v "$PWD:/workspace" \
|
||||
-w /workspace \
|
||||
lifemaps/ci-cpp:latest \
|
||||
bash -lc '
|
||||
cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Debug &&
|
||||
cmake --build build --parallel &&
|
||||
ctest --test-dir build --output-on-failure
|
||||
'
|
||||
```
|
||||
|
||||
Damit wird dieselbe Toolchain verwendet wie in der Jenkins-CI.
|
||||
|
||||
|
||||
## Policy-Check lokal im CI-Container ausführen
|
||||
|
||||
```bash
|
||||
docker run --rm -it \
|
||||
-v "$PWD:/workspace" \
|
||||
-w /workspace \
|
||||
lifemaps/ci-cpp:latest \
|
||||
bash -lc 'python3 ci/check_pr_policies.py'
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Verhalten in Jenkins
|
||||
|
||||
Die Jenkins-Pipeline umfasst typischerweise diese Stages:
|
||||
|
||||
1. **Checkout**
|
||||
2. **Policy Checks**
|
||||
3. **Configure**
|
||||
4. **Build**
|
||||
5. **Test**
|
||||
6. **Cleanup**
|
||||
|
||||
Wenn die Policy-Checks fehlschlagen, werden die späteren Build- und Test-Stages nicht mehr ausgeführt.
|
||||
|
||||
---
|
||||
|
||||
## Typische Fehlerursachen
|
||||
|
||||
### Formatfehler
|
||||
Beispiel:
|
||||
```text
|
||||
ERROR: Formatfehler in tests/test_main.cpp
|
||||
```
|
||||
|
||||
#### Lösung
|
||||
```bash
|
||||
clang-format -i tests/test_main.cpp
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Kein passender Test gefunden
|
||||
Beispiel:
|
||||
```text
|
||||
ERROR: Kein passender Test unter tests/, test/ oder qt6-after/qt6-migrated-benchmark/tests für main.cpp gefunden.
|
||||
```
|
||||
|
||||
#### Lösung
|
||||
- passenden Test anlegen
|
||||
- Testdatei passend benennen
|
||||
- Test in einem der erlaubten Testverzeichnisse ablegen
|
||||
|
||||
---
|
||||
|
||||
### Commit nicht gültig SSH-signiert
|
||||
Beispiel:
|
||||
```text
|
||||
ERROR: Commit ist nicht gültig mit erlaubtem SSH-Signierer signiert: <sha>
|
||||
```
|
||||
|
||||
#### Lösung
|
||||
- SSH-Signing lokal korrekt konfigurieren
|
||||
- prüfen, ob der richtige Schlüssel verwendet wird
|
||||
- prüfen, ob der öffentliche Schlüssel in `ci/allowed_signers` eingetragen ist
|
||||
- Commit neu erstellen oder neu signieren
|
||||
|
||||
---
|
||||
|
||||
### `.clang-format` fehlt
|
||||
Beispiel:
|
||||
```text
|
||||
ERROR: .clang-format fehlt im Repository-Root.
|
||||
```
|
||||
|
||||
#### Lösung
|
||||
- `.clang-format` im Repository-Root anlegen oder wiederherstellen
|
||||
|
||||
---
|
||||
|
||||
## Empfohlener Workflow
|
||||
|
||||
1. Feature-Branch erstellen
|
||||
2. Änderungen implementieren
|
||||
3. Test ergänzen oder anpassen
|
||||
4. Code formatieren
|
||||
5. Commit SSH-signiert erstellen
|
||||
6. lokal Policy, Build und Tests ausführen
|
||||
7. pushen
|
||||
8. Pull Request öffnen
|
||||
9. Jenkins-Ergebnis prüfen
|
||||
10. erst bei grünem Status mergen
|
||||
|
||||
---
|
||||
|
||||
## Kurz-Checkliste vor jedem Push
|
||||
|
||||
- [ ] C/C++-Dateien sind formatiert
|
||||
- [ ] passender Test existiert
|
||||
- [ ] Commit ist SSH-signiert
|
||||
- [ ] öffentlicher Schlüssel steht in `ci/allowed_signers`
|
||||
- [ ] `python3 ci/check_pr_policies.py` läuft erfolgreich
|
||||
- [ ] Build und Tests laufen lokal
|
||||
|
||||
---
|
||||
|
||||
## Ziel der Regeln
|
||||
|
||||
Die Policies sollen sicherstellen, dass:
|
||||
|
||||
- Code konsistent formatiert ist
|
||||
- Änderungen nachvollziehbar getestet sind
|
||||
- nur autorisierte Signierer Commits einbringen
|
||||
- PRs frühzeitig automatisiert validiert werden
|
||||
@@ -0,0 +1,280 @@
|
||||
# scripts/
|
||||
|
||||
Dieses Verzeichnis enthält Hilfsskripte für den Demo- und Benchmark-Workflow rund um:
|
||||
|
||||
- **Qt5 → Qt6**
|
||||
- **C++11 → C++23**
|
||||
- **Copilot CLI**
|
||||
- **Entire CLI**
|
||||
- **Scaleway BYOK / OpenAI-kompatibler Provider**
|
||||
- **lokale Reproduzierbarkeit der Migration**
|
||||
|
||||
## Übersicht
|
||||
|
||||
### `create-qt5-legacy-benchmark.sh`
|
||||
Erzeugt das Legacy-Beispielprojekt unter:
|
||||
|
||||
```text
|
||||
qt5-before/qt5-legacy-migration-benchmark
|
||||
```
|
||||
|
||||
Das Projekt ist absichtlich veraltet aufgebaut, um eine realistische Migration zu erzwingen, z. B. mit:
|
||||
|
||||
- `QRegExp`
|
||||
- `QDesktopWidget`
|
||||
- `QTextCodec`
|
||||
- alter `SIGNAL/SLOT`-Syntax
|
||||
- `Qt5::Core`, `Qt5::Gui`, `Qt5::Widgets`
|
||||
- `C++11`
|
||||
|
||||
### `run-entire-copilot-migration.sh`
|
||||
Standard-Workflow für eine Copilot-CLI-Migration mit Entire:
|
||||
|
||||
1. Entire für Copilot CLI aktivieren
|
||||
2. Baseline committen
|
||||
3. Copilot-Session starten
|
||||
4. Ergebnis committen
|
||||
5. Checkpoints anzeigen
|
||||
6. letzten Stand mit Entire erklären
|
||||
|
||||
Dieses Skript ist für den normalen Migrationslauf gedacht.
|
||||
|
||||
**Modellwahl:**
|
||||
Das Skript akzeptiert optional ein Modell als zweiten Parameter.
|
||||
|
||||
Default:
|
||||
|
||||
```bash
|
||||
./scripts/run-entire-copilot-migration.sh
|
||||
```
|
||||
|
||||
verwendet intern:
|
||||
|
||||
```bash
|
||||
copilot --model "qwen3.5-397b-a17b"
|
||||
```
|
||||
|
||||
Mit explizitem Modell:
|
||||
|
||||
```bash
|
||||
./scripts/run-entire-copilot-migration.sh qt5-before/qt5-legacy-migration-benchmark gpt-5
|
||||
```
|
||||
|
||||
### `run-entire-copilot-migration-with-optional-rewind-resume.sh`
|
||||
Wie das Standardskript, aber zusätzlich mit optionalem:
|
||||
|
||||
- `entire checkpoint rewind`
|
||||
- `entire session resume <branch>`
|
||||
|
||||
**Modellwahl:**
|
||||
Auch dieses Skript akzeptiert optional ein Modell als zweiten Parameter.
|
||||
|
||||
Beispiel:
|
||||
|
||||
```bash
|
||||
./scripts/run-entire-copilot-migration-with-optional-rewind-resume.sh qt5-before/qt5-legacy-migration-benchmark claude-sonnet-4
|
||||
```
|
||||
|
||||
**Wichtig:**
|
||||
Die Entire-Dokumentation ist bei Copilot CLI in Bezug auf Rewind/Resume nicht ganz konsistent.
|
||||
Die Copilot-CLI-Seite beschreibt Rewind und Resume, während die allgemeine Agent-Übersicht teils eingeschränkte Aussagen macht.
|
||||
|
||||
Darum behandelt dieses Skript Rewind/Resume bewusst als **optional** und **fehlertolerant**.
|
||||
|
||||
### `use-scaleway-copilot-debug.sh`
|
||||
Hilfsskript zum Setzen einer **Scaleway OpenAI-kompatiblen BYOK-Konfiguration** für Copilot CLI.
|
||||
|
||||
Typischer Zweck:
|
||||
|
||||
- Provider-Umgebungsvariablen setzen
|
||||
- Copilot CLI mit Scaleway testen
|
||||
- Modellname konfigurieren
|
||||
- Token-Limits für nicht im Copilot-Katalog enthaltene Modelle explizit setzen
|
||||
- Debugging eines externen Providers vereinfachen
|
||||
|
||||
Ein typischer Inhalt wäre z. B.:
|
||||
|
||||
- `COPILOT_PROVIDER_TYPE=openai`
|
||||
- `COPILOT_PROVIDER_BASE_URL=https://api.scaleway.ai/v1`
|
||||
- `COPILOT_PROVIDER_API_KEY=...`
|
||||
- `COPILOT_MODEL=qwen3.5-397b-a17b`
|
||||
- `COPILOT_PROVIDER_MAX_PROMPT_TOKENS=...`
|
||||
- `COPILOT_PROVIDER_MAX_OUTPUT_TOKENS=...`
|
||||
|
||||
---
|
||||
|
||||
## NOTE: Secret in `.envrc` hinterlegen
|
||||
|
||||
Das Secret für den verwendeten LLM-Provider soll **nicht** direkt in die Skripte geschrieben oder committed werden.
|
||||
|
||||
Lege den API-Key stattdessen in einer lokalen `.envrc` ab, z. B.:
|
||||
|
||||
```bash
|
||||
export SCW_SECRET_KEY="YOUR_PROVIDER_SECRET_HERE"
|
||||
```
|
||||
|
||||
oder allgemeiner:
|
||||
|
||||
```bash
|
||||
export OPENAI_API_KEY="YOUR_PROVIDER_SECRET_HERE"
|
||||
```
|
||||
|
||||
Danach die Umgebung neu laden, z. B. mit:
|
||||
|
||||
```bash
|
||||
direnv allow
|
||||
```
|
||||
|
||||
oder die Datei manuell sourcen, falls du kein `direnv` verwendest.
|
||||
|
||||
**Wichtig:**
|
||||
- `.envrc` nicht committen
|
||||
- Secrets nicht im Repository speichern
|
||||
- Provider-Zugangsdaten nur lokal halten
|
||||
|
||||
---
|
||||
|
||||
## Empfohlene Reihenfolge
|
||||
|
||||
### 1. Legacy-Projekt erzeugen
|
||||
|
||||
```bash
|
||||
./scripts/create-qt5-legacy-benchmark.sh
|
||||
```
|
||||
|
||||
### 2. Optional: Copilot mit Scaleway konfigurieren
|
||||
|
||||
```bash
|
||||
source ./scripts/use-scaleway-copilot-debug.sh
|
||||
```
|
||||
|
||||
Danach kannst du prüfen, ob die Variablen gesetzt sind:
|
||||
|
||||
```bash
|
||||
echo "$COPILOT_PROVIDER_BASE_URL"
|
||||
echo "$COPILOT_MODEL"
|
||||
```
|
||||
|
||||
### 3. Migration mit Entire + Copilot starten
|
||||
|
||||
Standard mit Default-Modell:
|
||||
|
||||
```bash
|
||||
./scripts/run-entire-copilot-migration.sh qt5-before/qt5-legacy-migration-benchmark
|
||||
```
|
||||
|
||||
Standard mit explizitem Modell:
|
||||
|
||||
```bash
|
||||
./scripts/run-entire-copilot-migration.sh qt5-before/qt5-legacy-migration-benchmark qwen3.5-397b-a17b
|
||||
```
|
||||
|
||||
Mit optionalem Rewind/Resume:
|
||||
|
||||
```bash
|
||||
./scripts/run-entire-copilot-migration-with-optional-rewind-resume.sh qt5-before/qt5-legacy-migration-benchmark qwen3.5-397b-a17b
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Copilot-Prompt für die Migration
|
||||
|
||||
Die Migrationsskripte verwenden sinngemäß einen Prompt in dieser Richtung:
|
||||
|
||||
```text
|
||||
Migrate the legacy Qt5/C++11 desktop application to Qt6/C++23.
|
||||
|
||||
Requirements:
|
||||
- Read the legacy source project from qt5-before/qt5-legacy-migration-benchmark
|
||||
- Write the migrated project into qt6-after/qt6-migrated-benchmark
|
||||
- Do not modify the legacy source tree in place
|
||||
- Update CMake from Qt5 to Qt6
|
||||
- Keep Core, Gui, and Widgets explicitly linked
|
||||
- Replace QRegExp with QRegularExpression
|
||||
- Replace QDesktopWidget / QApplication::desktop() usage with QScreen-based Qt6 APIs
|
||||
- Remove legacy QTextCodec usage and use modern Qt6-safe text handling
|
||||
- Modernize old SIGNAL/SLOT syntax to function-pointer connect syntax
|
||||
- Replace legacy null pointer literals with nullptr
|
||||
- Preserve the .ui and .qrc integration
|
||||
- Preserve application behavior
|
||||
- Upgrade the project from C++11 to C++23
|
||||
- For every code change inside a method, add at least three tests covering the changed behavior
|
||||
- Place all generated tests in qt6-after/qt6-migrated-benchmark/tests
|
||||
- Update CMake so the migrated application and all tests build successfully with CTest
|
||||
- Keep the test file naming compatible with repository policy checks
|
||||
- Briefly explain each migration change
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Entire-Hinweise
|
||||
|
||||
Entire erfasst bei unterstützten Agenten u. a.:
|
||||
|
||||
- Gesprächsverlauf
|
||||
- Dateiveränderungen
|
||||
- Zeitstempel
|
||||
- Checkpoints bei Commits
|
||||
- Session-Kontext auf dem Branch `entire/checkpoints/v1`
|
||||
|
||||
Typischer Entire-Grundablauf:
|
||||
|
||||
```bash
|
||||
entire agent add copilot-cli
|
||||
copilot --model "qwen3.5-397b-a17b"
|
||||
git add .
|
||||
git commit -m "..."
|
||||
entire checkpoint list
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Hinweise zu `use-scaleway-copilot-debug.sh`
|
||||
|
||||
Das Skript sollte **gesourct** werden, nicht als eigener Prozess laufen, damit exportierte Variablen in deiner aktuellen Shell erhalten bleiben:
|
||||
|
||||
```bash
|
||||
source ./scripts/use-scaleway-copilot-debug.sh
|
||||
```
|
||||
|
||||
oder kurz:
|
||||
|
||||
```bash
|
||||
. ./scripts/use-scaleway-copilot-debug.sh
|
||||
```
|
||||
|
||||
Außerdem:
|
||||
|
||||
- keine echten Secrets committen
|
||||
- API-Keys nicht im Repo speichern
|
||||
- sensible Werte aus `.envrc` oder bereits gesetzten Umgebungsvariablen übernehmen
|
||||
|
||||
Beispiel:
|
||||
|
||||
```bash
|
||||
export SCW_SECRET_KEY="..."
|
||||
source ./scripts/use-scaleway-copilot-debug.sh
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Empfohlene Erweiterungen
|
||||
|
||||
Optional kannst du später noch ergänzen:
|
||||
|
||||
- `build-qt6-after.sh`
|
||||
- `run-ctest-qt6-after.sh`
|
||||
- `compare-before-after.sh`
|
||||
- `capture-copilot-env.sh`
|
||||
|
||||
---
|
||||
|
||||
## Kurzfassung
|
||||
|
||||
Der `scripts/`-Ordner enthält alles, um:
|
||||
|
||||
1. ein Legacy-Qt5-Projekt zu erzeugen,
|
||||
2. Copilot CLI optional mit einem externen Modell zu konfigurieren,
|
||||
3. Secrets lokal über `.envrc` bereitzustellen,
|
||||
4. eine Qt6/C++23-Migration mit Entire zu dokumentieren,
|
||||
5. und den Migrationslauf reproduzierbar zu machen.
|
||||
@@ -0,0 +1,97 @@
|
||||
# Copilot CLI mit Scaleway verwenden
|
||||
|
||||
## 1) `.envrc` anlegen
|
||||
|
||||
Lege in deinem Projekt eine Datei `.envrc` an:
|
||||
|
||||
```bash name=.envrc
|
||||
export STRIX_LLM="qwen3.5-397b-a17b"
|
||||
export SCW_SECRET_KEY="REPLACE_WITH_YOURS"
|
||||
|
||||
export COPILOT_PROVIDER_TYPE="openai"
|
||||
export COPILOT_PROVIDER_API_KEY="${SCW_SECRET_KEY}"
|
||||
export COPILOT_PROVIDER_BASE_URL="https://api.scaleway.ai/v1"
|
||||
export COPILOT_MODEL="${STRIX_LLM}"
|
||||
|
||||
export COPILOT_PROVIDER_MAX_PROMPT_TOKENS="32768"
|
||||
export COPILOT_PROVIDER_MAX_OUTPUT_TOKENS="8192"
|
||||
```
|
||||
|
||||
## 2) `direnv` erlauben
|
||||
|
||||
Falls `direnv` schon installiert ist:
|
||||
|
||||
```bash name=direnv-allow.sh
|
||||
direnv allow
|
||||
```
|
||||
|
||||
Wenn noch nicht in der Shell aktiviert, ergänze deine Shell-Config.
|
||||
|
||||
### Bash
|
||||
```bash name=bash-direnv-hook.sh
|
||||
eval "$(direnv hook bash)"
|
||||
```
|
||||
|
||||
### Zsh
|
||||
```bash name=zsh-direnv-hook.sh
|
||||
eval "$(direnv hook zsh)"
|
||||
```
|
||||
|
||||
Danach Shell neu laden:
|
||||
|
||||
```bash name=reload-shell-config.sh
|
||||
source ~/.bashrc
|
||||
# oder
|
||||
source ~/.zshrc
|
||||
```
|
||||
|
||||
## 3) Startskript anlegen
|
||||
|
||||
```bash name=use-scaleway-copilot.sh
|
||||
#!/usr/bin/env bash
|
||||
set -euo pipefail
|
||||
|
||||
if ! command -v copilot >/dev/null 2>&1; then
|
||||
echo "copilot CLI nicht gefunden."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
: "${COPILOT_PROVIDER_TYPE:?COPILOT_PROVIDER_TYPE fehlt}"
|
||||
: "${COPILOT_PROVIDER_API_KEY:?COPILOT_PROVIDER_API_KEY fehlt}"
|
||||
: "${COPILOT_PROVIDER_BASE_URL:?COPILOT_PROVIDER_BASE_URL fehlt}"
|
||||
: "${COPILOT_MODEL:?COPILOT_MODEL fehlt}"
|
||||
|
||||
echo "Starte Copilot CLI mit:"
|
||||
echo " Provider: ${COPILOT_PROVIDER_TYPE}"
|
||||
echo " Base URL: ${COPILOT_PROVIDER_BASE_URL}"
|
||||
echo " Modell: ${COPILOT_MODEL}"
|
||||
|
||||
exec copilot "$@"
|
||||
```
|
||||
|
||||
Dann ausführbar machen:
|
||||
|
||||
```bash name=chmod-script.sh
|
||||
chmod +x use-scaleway-copilot.sh
|
||||
```
|
||||
|
||||
Start:
|
||||
|
||||
```bash name=start-script.sh
|
||||
./use-scaleway-copilot.sh
|
||||
```
|
||||
|
||||
Oder mit Argumenten:
|
||||
|
||||
```bash name=start-script-with-args.sh
|
||||
./use-scaleway-copilot.sh --model="qwen3.5-397b-a17b"
|
||||
```
|
||||
|
||||
## 4) `.gitignore` ergänzen
|
||||
|
||||
Falls noch nicht vorhanden:
|
||||
|
||||
```gitignore name=.gitignore
|
||||
.env
|
||||
.envrc
|
||||
```
|
||||
Reference in new issue
Block a user