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

New issue

Open

opened 2026-05-13 11:28:09 +00:00 by maximus · 0 comments

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