ENI-projet-piscine

421 Commits 88 Branches 0 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
Johan LEROY	10cc408b03	feat(deploy): ajoute un environnement dev déployé à la demande Infra / Formatage et validation Terraform (push) Successful in 50s Details Troisième projet Compose sur la VM ENI, /srv/enervision/dev, alimenté par workflow_dispatch de n'importe quelle branche autre que dev et main (https://dev.enervision.local:9443). La recette suit toujours dev, la production main. - deploy.yml : routage main -> prod, dev -> rec, autre -> dev ; groupe de concurrence par environnement et non plus par branche. - provision-host.sh : prépare le dossier dev (ports 9443, 5435, 8027, 8084) ; passe safe.directory à git, faute de quoi un second passage en root, celui de terraform apply, échoue sur les clones déjà remis au runner. - ADR 0017, 10-infra.md, 50-cicd.md, infra/README.md à jour.	2026-09-23 10:43:48 +02:00
Johan LEROYandClaude Opus 5	357cf996ed	fix(infra): donne au runner un nom distinct de son label Infra / Formatage et validation Terraform (push) Successful in 9s Details --name reprenait runner_labels : un runner et son label portaient le meme eni-g3. Deux machines qui reprendraient cette racine s'enregistreraient sous le meme nom, ce que GitHub refuse. Le nom vaut desormais celui de l'hote, resolu sur la machine, et runner_nom permet de le forcer. Point 2 de la revue de la PR #144. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-09-22 12:36:38 +02:00
Johan LEROY	0db69fd023	feat(infra): Terraform provisionne la VM, GitHub Actions continue de déployer Le seul Terraform du dépôt installait un cluster k3s que rien ne consomme, et sa racine ne passait même pas `terraform init` : depuis Terraform 1.x, un provisioner `destroy` impose que tout le bloc `connection` ne lise que `self`, et celui du module k3s lisait `var.`. Il est corrigé en batissant la connexion sur `triggers`, où ne figurent que l'adresse, le port, l'utilisateur et le chemin de la clé : jamais la clé ni un mot de passe. `environments/vm-eni` provisionne la machine qui porte la recette et la production : Docker et le plugin Compose, `scripts/provision-host.sh`, puis l'enregistrement du runner. Rien n'y construit d'image ni ne lance de conteneur, et un `apply` n'interrompt pas la stack qui tourne. Le déploiement continu ne bouge pas : `deploy.yml` reste le seul chemin de livraison. `environments/dev` devient `k3s-cible`, parce qu'il provisionnait un cluster et pas un environnement applicatif, et que `rec` et `prod` vivent sur la même machine. `environments/prod`, dossier vide, disparaît. `infra.yml` formate et valide chaque racine à chaque push : c'est l'absence d'un tel job qui a laissé ce Terraform cassé sans que rien ne le dise. La boucle parcourt `environments/`, une racine ajoutée est couverte sans y toucher. ADR 0010 pour la frontière entre provisionnement et livraison, et la doc d'architecture alignée dessus.	2026-09-22 11:27:21 +02:00

Author

SHA1

Message

Date

Johan LEROY

10cc408b03

feat(deploy): ajoute un environnement dev déployé à la demande

Infra / Formatage et validation Terraform (push) Successful in 50s

Details

Troisième projet Compose sur la VM ENI, /srv/enervision/dev, alimenté par
workflow_dispatch de n'importe quelle branche autre que dev et main
(https://dev.enervision.local:9443). La recette suit toujours dev, la
production main.

- deploy.yml : routage main -> prod, dev -> rec, autre -> dev ; groupe de
  concurrence par environnement et non plus par branche.
- provision-host.sh : prépare le dossier dev (ports 9443, 5435, 8027, 8084) ;
  passe safe.directory à git, faute de quoi un second passage en root, celui
  de terraform apply, échoue sur les clones déjà remis au runner.
- ADR 0017, 10-infra.md, 50-cicd.md, infra/README.md à jour.

2026-09-23 10:43:48 +02:00

Johan LEROYandClaude Opus 5

357cf996ed

fix(infra): donne au runner un nom distinct de son label

Infra / Formatage et validation Terraform (push) Successful in 9s

Details

--name reprenait runner_labels : un runner et son label portaient le meme
eni-g3. Deux machines qui reprendraient cette racine s'enregistreraient sous
le meme nom, ce que GitHub refuse. Le nom vaut desormais celui de l'hote,
resolu sur la machine, et runner_nom permet de le forcer.

Point 2 de la revue de la PR #144.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-09-22 12:36:38 +02:00

Johan LEROY

0db69fd023

feat(infra): Terraform provisionne la VM, GitHub Actions continue de déployer

Le seul Terraform du dépôt installait un cluster k3s que rien ne consomme, et
sa racine ne passait même pas `terraform init` : depuis Terraform 1.x, un
provisioner `destroy` impose que tout le bloc `connection` ne lise que `self`,
et celui du module k3s lisait `var.*`. Il est corrigé en batissant la connexion
sur `triggers`, où ne figurent que l'adresse, le port, l'utilisateur et le
chemin de la clé : jamais la clé ni un mot de passe.

`environments/vm-eni` provisionne la machine qui porte la recette et la
production : Docker et le plugin Compose, `scripts/provision-host.sh`, puis
l'enregistrement du runner. Rien n'y construit d'image ni ne lance de
conteneur, et un `apply` n'interrompt pas la stack qui tourne. Le déploiement
continu ne bouge pas : `deploy.yml` reste le seul chemin de livraison.

`environments/dev` devient `k3s-cible`, parce qu'il provisionnait un cluster et
pas un environnement applicatif, et que `rec` et `prod` vivent sur la même
machine. `environments/prod`, dossier vide, disparaît.

`infra.yml` formate et valide chaque racine à chaque push : c'est l'absence
d'un tel job qui a laissé ce Terraform cassé sans que rien ne le dise. La
boucle parcourt `environments/*`, une racine ajoutée est couverte sans y
toucher.

ADR 0010 pour la frontière entre provisionnement et livraison, et la doc
d'architecture alignée dessus.

2026-09-22 11:27:21 +02:00