fix(coolify): REPORTS_DIR mal cable + bind-mount des scan reports manquant #10

New issue

Closed

opened 2026-05-13 11:28:09 +00:00 by maximus · 1 comment

maximus commented

2026-05-13 11:28:09 +00:00

Owner

Symptome

GET /reports/scans?date=2026-05-13 retourne {count: 0, reports: []} alors que 9 rapports de scan existent sur le VPS pour cette date. Consequence : defenseur-auto sur la workstation Max charge 0 finding chaque nuit (scan reports loaded — 0 report(s)), aucune PR auto n'est ouverte. Cas vecu cette nuit (2026-05-13) : 2 HIGH deps sur la-suite-booking (fast-uri, next) + 1 MEDIUM sur bardes (postcss) ignores.

Cause racine

Le conteneur Coolify vps-health-api (resource spotless-seahorse-..., app id 1) a :

env REPORTS_DIR=/data/scans — chemin inexistant dans le conteneur
bind-mount unique : /data/defenseurs -> /data/defenseurs (host:container)
contenu host /data/defenseurs/ : juste status.json + agents-map.json, pas de sous-dir reports/

Les rapports de scan vivent cote host dans /home/defenseur/defenseurs/reports/archive/, jamais exposes au conteneur. Le code index.js:10 defaulte sur /data/defenseurs/reports (correct par defaut) mais l'env override pointe ailleurs ET le chemin n'est pas mount.

La TODO manuelle post-merge de la PR #6 (notee dans defenseurs/STATE.md 2026-05-07 — "Manuel post-merge : env var Coolify REPORTS_DIR=/data/defenseurs/reports") n'a jamais ete executee. Pas d'issue de tracking.

Fix

Sur le VPS :

sudo ln -s /home/defenseur/defenseurs/reports /data/defenseurs/reports

Dans Coolify (app vps-health-api) :

Env var REPORTS_DIR : /data/scans → /data/defenseurs/reports
Redeploy

Validation

curl -H "Authorization: Bearer $HEALTH_TOKEN" \
  https://health.lacompagniemaximus.com/reports/scans?date=2026-05-13
# Doit retourner count >= 9

Puis le prochain run defenseur-auto (cron workstation 02:00 Montreal) devrait charger les findings et ouvrir des PRs sur les repos enabled (booking, denicheurs, famille, maximus, simpl-liste, Simpl-Resultat, vps-health-api).

Note suivi

Ajouter une verification dans test-curl.sh ou un healthcheck qui detecte count: 0 persistant comme signal d'alerte (eviter une regression silencieuse de meme nature).

## Symptome `GET /reports/scans?date=2026-05-13` retourne `{count: 0, reports: []}` alors que 9 rapports de scan existent sur le VPS pour cette date. Consequence : `defenseur-auto` sur la workstation Max charge 0 finding chaque nuit (`scan reports loaded — 0 report(s)`), aucune PR auto n'est ouverte. Cas vecu cette nuit (2026-05-13) : 2 HIGH deps sur `la-suite-booking` (fast-uri, next) + 1 MEDIUM sur `bardes` (postcss) ignores. ## Cause racine Le conteneur Coolify `vps-health-api` (resource `spotless-seahorse-...`, app id 1) a : - env `REPORTS_DIR=/data/scans` — chemin inexistant dans le conteneur - bind-mount unique : `/data/defenseurs -> /data/defenseurs` (host:container) - contenu host `/data/defenseurs/` : juste `status.json` + `agents-map.json`, pas de sous-dir `reports/` Les rapports de scan vivent cote host dans `/home/defenseur/defenseurs/reports/archive/`, jamais exposes au conteneur. Le code `index.js:10` defaulte sur `/data/defenseurs/reports` (correct par defaut) mais l'env override pointe ailleurs ET le chemin n'est pas mount. La TODO manuelle post-merge de la PR #6 (notee dans `defenseurs/STATE.md` 2026-05-07 — *"Manuel post-merge : env var Coolify REPORTS_DIR=/data/defenseurs/reports"*) n'a jamais ete executee. Pas d'issue de tracking. ## Fix Sur le VPS : ```bash sudo ln -s /home/defenseur/defenseurs/reports /data/defenseurs/reports ``` Dans Coolify (app vps-health-api) : - Env var `REPORTS_DIR` : `/data/scans` → `/data/defenseurs/reports` - Redeploy ## Validation ```bash curl -H "Authorization: Bearer $HEALTH_TOKEN" \ https://health.lacompagniemaximus.com/reports/scans?date=2026-05-13 # Doit retourner count >= 9 ``` Puis le prochain run defenseur-auto (cron workstation 02:00 Montreal) devrait charger les findings et ouvrir des PRs sur les repos enabled (booking, denicheurs, famille, maximus, simpl-liste, Simpl-Resultat, vps-health-api). ## Note suivi Ajouter une verification dans `test-curl.sh` ou un healthcheck qui detecte `count: 0` persistant comme signal d'alerte (eviter une regression silencieuse de meme nature).

maximus commented

2026-07-16 00:47:39 +00:00

Author

Owner

Fix reel :

Persistent Storage Coolify : /home/defenseur/defenseurs/reports -> /data/defenseurs/reports (Directory Mount via UI — aucun endpoint API storages, et custom_docker_run_options ignore -v silencieusement, gotcha documente dans la-compagnie-maximus/docs/coolify-ops.md)
Env REPORTS_DIR corrigee : /data/scans -> /data/defenseurs/reports (chemin canonique)
Redeploy

Validation : GET /reports/scans?date=2026-07-13 -> count=10 (10 agents), idem 2026-07-14.

Note : defenseur-auto (consommateur original) est en voie d'abandon — l'endpoint et ce fix restent necessaires pour /defenseurs/findings (PR #9, mergee) qui lit le meme REPORTS_DIR.

Regle en prod le 2026-07-15 — autrement que decrit ici : le symlink propose ne pouvait pas fonctionner. Un symlink est resolu au moment de la lecture, dans le namespace de celui qui lit ; dans le conteneur, `/home/defenseur/` n'existe pas -> lien mort, meme symptome (`existsSync` false, count 0 silencieux). Fix reel : - Persistent Storage Coolify : `/home/defenseur/defenseurs/reports` -> `/data/defenseurs/reports` (Directory Mount via UI — aucun endpoint API storages, et `custom_docker_run_options` ignore `-v` silencieusement, gotcha documente dans `la-compagnie-maximus/docs/coolify-ops.md`) - Env `REPORTS_DIR` corrigee : `/data/scans` -> `/data/defenseurs/reports` (chemin canonique) - Redeploy Validation : `GET /reports/scans?date=2026-07-13` -> `count=10` (10 agents), idem `2026-07-14`. Note : `defenseur-auto` (consommateur original) est en voie d'abandon — l'endpoint et ce fix restent necessaires pour `/defenseurs/findings` (PR #9, mergee) qui lit le meme `REPORTS_DIR`.