68 lines
2.0 KiB
Markdown
68 lines
2.0 KiB
Markdown
# `docs/CONFIG-ENV.md`
|
||
|
||
```md
|
||
# CONFIG-ENV — variables, priorités, injection build
|
||
|
||
## 0) Ce que la prod doit garantir
|
||
Le bouton “Proposer” doit ouvrir :
|
||
- `PUBLIC_GITEA_BASE` (domaine Gitea)
|
||
- `PUBLIC_GITEA_OWNER=Archicratia`
|
||
- `PUBLIC_GITEA_REPO=archicratie-edition`
|
||
|
||
Si un seul de ces 3 paramètres est faux → on obtient :
|
||
- 404 / redirect login inattendu
|
||
- ou un repo/owner incorrect
|
||
|
||
## 1) Variables utilisées (publique, côté build Astro)
|
||
|
||
- `PUBLIC_GITEA_BASE`
|
||
- `PUBLIC_GITEA_OWNER`
|
||
- `PUBLIC_GITEA_REPO`
|
||
|
||
Elles sont consommées via `import.meta.env.PUBLIC_*` dans `EditionLayout.astro`.
|
||
|
||
## 2) Où elles vivent (en pratique)
|
||
Sur NAS, vous avez vu des divergences entre :
|
||
- `.env`
|
||
- `.env.local`
|
||
- `.env.production`
|
||
|
||
Règle :
|
||
- **prod build docker** doit être piloté par **`.env`** (ou `.env.production` si vous standardisez ainsi),
|
||
- mais on évite que `.env.local` “corrige en douce” un `.env` faux.
|
||
|
||
## 3) Vérification rapide (NAS)
|
||
en sh
|
||
for f in .env .env.local .env.production .env.production.local; do
|
||
[ -f "$f" ] && echo "---- $f" && grep -nE '^PUBLIC_GITEA_(BASE|OWNER|REPO)=' "$f" || true
|
||
done
|
||
|
||
## 4) Injection Docker (ce qui doit être vrai)
|
||
|
||
Le build passe bien les build-args :
|
||
|
||
--build-arg PUBLIC_GITEA_BASE=...
|
||
|
||
--build-arg PUBLIC_GITEA_OWNER=...
|
||
|
||
--build-arg PUBLIC_GITEA_REPO=...
|
||
|
||
et le Dockerfile expose via ENV pour Astro build.
|
||
|
||
## 5) Contrôle “résultat dans le HTML”
|
||
|
||
Après build, vérifier que la page contient le bon chemin /issues/new vers le bon owner/repo :
|
||
|
||
curl -fsS http://127.0.0.1:8082/archicratie/archicrat-ia/chapitre-4/ > /tmp/page.html
|
||
grep -nE 'issues/new|archicratie-edition|Archicratia' /tmp/page.html | head -n 40
|
||
|
||
## 6) Secrets (à ne pas committer)
|
||
|
||
GITEA_TOKEN : jamais dans le repo.
|
||
|
||
Le token peut être utilisé ponctuellement pour push non-interactif, mais doit rester dans l’environnement local/CI.
|
||
|
||
## 7) Docker BuildKit / API (si besoin)
|
||
|
||
Si BuildKit/buildx est instable sur la machine, vous avez déjà un protocole “fonctionnel”.
|
||
Ne documenter ici que le “standard validé” (voir DEPLOY_PROD). |