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

Diagnostic — “Proposer” (résumé)

Symptôme : clic “Proposer” → 404 / login / mauvais repo
Cause la plus fréquente : PUBLIC_GITEA_OWNER (casse sensible) ou PUBLIC_GITEA_REPO faux.

➡️ Procédure complète (pas-à-pas + commandes) : voir docs/TROUBLESHOOTING.md#proposer-404.

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).

2.3 KiB Raw Blame History Unescape Escape