maximus/vps-health-api

Fork 0

infra: configurer webhook Forgejo + auto_deploy Coolify pour auto-rebuild #7

New issue

Closed

opened 2026-05-08 01:37:20 +00:00 by maximus · 1 comment

maximus commented

2026-05-08 01:37:20 +00:00

Owner

Contexte

Le merge de PR #6 (feat(reports): add GET /reports/scans) le 2026-05-08 01:23 UTC n'a PAS declenche de rebuild Coolify :

last_online_at Coolify : 2026-05-08 01:19:13 (avant le merge)
GET https://health.lacompagniemaximus.com/reports/scans?date=... -> HTTP 404 (route absente) jusqu'au redeploy manuel via UI

Le CLAUDE.md du projet affirme :

Deploy

Coolify auto-rebuild depuis push Forgejo. Aucune action manuelle requise.

Faux dans l'etat actuel. Drift de config a corriger.

Cause racine (diagnostic 2026-05-08)

Forgejo cote : aucun webhook configure sur maximus/vps-health-api.

GET https://git.lacompagniemaximus.com/api/v1/repos/maximus/vps-health-api/hooks
-> []

Coolify cote : auto_deploy: None sur l'app vps-health-api (uuid u8000gsg044wsk0oo0w884ok, slug spotless-seahorse-y4gwocg8k8088g04cgosk00g).

Sans webhook ni auto-deploy, chaque merge sur main necessite un trigger manuel via UI Coolify.

Travail a faire

Activer auto_deploy=true sur l'app Coolify u8000gsg044wsk0oo0w884ok
Recuperer URL webhook + secret HMAC depuis Coolify (UI : app -> "Webhooks" / "Source")
Creer le webhook Forgejo sur maximus/vps-health-api :
- URL : webhook Coolify
- Secret : HMAC fourni par Coolify
- Events : Push sur branche main uniquement
- Content-Type : application/json
Test E2E : merge PR doc triviale, observer last_online_at Coolify avancer dans la minute
Apres OK : check rapide auto_deploy sur les autres apps Coolify (maximus-api, feedback-api, ...). Si drift detecte sur 2+ apps, ouvrir issue umbrella separee dans la-compagnie-maximus pour le chantier infra global (hors scope ici)
Si la procedure revele un gotcha : ajouter encart dans la-compagnie-maximus/docs/coolify-ops.md section "Webhook Forgejo -> Coolify". Mentionner aussi que ~/.coolify-token actuel n'a pas la perm deploy (chantier token = separe)
Pas de modification de CLAUDE.md du projet : la phrase actuelle redevient vraie post-fix

Risque principal

Le type de "Source" Coolify (HTTPS clone URL vs Forgejo App integration) peut bloquer. L'auto-deploy webhook Coolify v4 fonctionne typiquement seulement avec une integration "App" (OAuth/PAT bidirectionnelle), pas un clone HTTPS direct.

Comparaison repos Coolify :

vps-health-api : git_repository = https://git.lacompagniemaximus.com/maximus/vps-health-api.git (HTTPS public/clone simple)
maximus-api : git_repository = git@git.lacompagniemaximus.com:22222/maximus/maximus-api.git (SSH via deploy key, port custom 22222)

Si le webhook ne peut pas etre wired sur la source actuelle, plan B : migrer vers integration "Source -> Private Repository (with Github / Gitea App)" + reconfigurer deploy key. C'est un re-provisioning leger (env vars conservees). Voir coolify-ops.md workflow type.

Verifications utiles

# Etat webhook Forgejo
curl -s -H "Authorization: token $(cat ~/.forgejo-token)" \
  https://git.lacompagniemaximus.com/api/v1/repos/maximus/vps-health-api/hooks

# Etat auto_deploy Coolify
curl -s -H "Authorization: Bearer $(cat ~/.coolify-token)" \
  https://coolify.lacompagniemaximus.com/api/v1/applications/u8000gsg044wsk0oo0w884ok \
  | python3 -c 'import sys,json; a=json.load(sys.stdin); print("auto_deploy:", a.get("auto_deploy"))'

# Audit cross-app (apres fix)
curl -s -H "Authorization: Bearer $(cat ~/.coolify-token)" \
  https://coolify.lacompagniemaximus.com/api/v1/applications \
  | python3 -c 'import sys,json
for a in json.load(sys.stdin):
    print(a["name"], "auto_deploy=", a.get("auto_deploy"))'

Decisions retenues (resolues via /analyze 2026-05-09)

Portee : fix isole sur vps-health-api (~10 min). Audit cross-app -> issue umbrella separee dans la-compagnie-maximus si drift detecte sur 2+ apps
Repo : issue reste dans vps-health-api (regression observee ici, contexte produit ici, meme si fix touche config externe)
Token deploy : hors scope. Le webhook server-to-server n'a pas besoin de token API. Mention dans coolify-ops.md que ~/.coolify-token actuel est read/write only
Doc CLAUDE.md : pas de modification (phrase actuelle redevient vraie post-fix)

Acceptation

Webhook Forgejo actif sur maximus/vps-health-api (events push sur main)
auto_deploy=true sur l'app Coolify
Test E2E : merge d'une PR triviale -> redeploy automatique observable dans Coolify dans la minute
Audit cross-app fait, resultat documente en commentaire de cette issue, umbrella creee si drift detecte
Doc coolify-ops.md a jour si la procedure a revele un gotcha

Surface de test

Pas de tests unitaires (config infra). Test de regression = test E2E ci-dessus (merge PR triviale -> redeploy auto).

Complexite

Simple — config infra hors code, ~10 min si la source Coolify est compatible webhook. Sinon Medium (re-provisioning source).

## Contexte Le merge de PR #6 (`feat(reports): add GET /reports/scans`) le 2026-05-08 01:23 UTC n'a PAS declenche de rebuild Coolify : - `last_online_at` Coolify : `2026-05-08 01:19:13` (avant le merge) - `GET https://health.lacompagniemaximus.com/reports/scans?date=...` -> `HTTP 404` (route absente) jusqu'au redeploy manuel via UI Le `CLAUDE.md` du projet affirme : > ## Deploy > Coolify auto-rebuild depuis push Forgejo. Aucune action manuelle requise. Faux dans l'etat actuel. Drift de config a corriger. ## Cause racine (diagnostic 2026-05-08) 1. **Forgejo cote** : aucun webhook configure sur `maximus/vps-health-api`. ``` GET https://git.lacompagniemaximus.com/api/v1/repos/maximus/vps-health-api/hooks -> [] ``` 2. **Coolify cote** : `auto_deploy: None` sur l'app `vps-health-api` (uuid `u8000gsg044wsk0oo0w884ok`, slug `spotless-seahorse-y4gwocg8k8088g04cgosk00g`). Sans webhook ni auto-deploy, chaque merge sur `main` necessite un trigger manuel via UI Coolify. ## Travail a faire - [ ] Activer `auto_deploy=true` sur l'app Coolify `u8000gsg044wsk0oo0w884ok` - [ ] Recuperer URL webhook + secret HMAC depuis Coolify (UI : app -> "Webhooks" / "Source") - [ ] Creer le webhook Forgejo sur `maximus/vps-health-api` : - URL : webhook Coolify - Secret : HMAC fourni par Coolify - Events : `Push` sur branche `main` uniquement - Content-Type : `application/json` - [ ] Test E2E : merge PR doc triviale, observer `last_online_at` Coolify avancer dans la minute - [ ] Apres OK : check rapide `auto_deploy` sur les autres apps Coolify (`maximus-api`, `feedback-api`, ...). Si drift detecte sur 2+ apps, **ouvrir issue umbrella separee dans `la-compagnie-maximus`** pour le chantier infra global (hors scope ici) - [ ] Si la procedure revele un gotcha : ajouter encart dans `la-compagnie-maximus/docs/coolify-ops.md` section "Webhook Forgejo -> Coolify". Mentionner aussi que `~/.coolify-token` actuel n'a pas la perm `deploy` (chantier token = separe) - [ ] Pas de modification de `CLAUDE.md` du projet : la phrase actuelle redevient vraie post-fix ## Risque principal Le type de "Source" Coolify (HTTPS clone URL vs Forgejo App integration) peut bloquer. L'auto-deploy webhook Coolify v4 fonctionne typiquement seulement avec une integration "App" (OAuth/PAT bidirectionnelle), pas un clone HTTPS direct. Comparaison repos Coolify : - `vps-health-api` : `git_repository = https://git.lacompagniemaximus.com/maximus/vps-health-api.git` (HTTPS public/clone simple) - `maximus-api` : `git_repository = git@git.lacompagniemaximus.com:22222/maximus/maximus-api.git` (SSH via deploy key, port custom 22222) Si le webhook ne peut pas etre wired sur la source actuelle, plan B : migrer vers integration "Source -> Private Repository (with Github / Gitea App)" + reconfigurer deploy key. C'est un re-provisioning leger (env vars conservees). Voir `coolify-ops.md` workflow type. ## Verifications utiles ```bash # Etat webhook Forgejo curl -s -H "Authorization: token $(cat ~/.forgejo-token)" \ https://git.lacompagniemaximus.com/api/v1/repos/maximus/vps-health-api/hooks # Etat auto_deploy Coolify curl -s -H "Authorization: Bearer $(cat ~/.coolify-token)" \ https://coolify.lacompagniemaximus.com/api/v1/applications/u8000gsg044wsk0oo0w884ok \ | python3 -c 'import sys,json; a=json.load(sys.stdin); print("auto_deploy:", a.get("auto_deploy"))' # Audit cross-app (apres fix) curl -s -H "Authorization: Bearer $(cat ~/.coolify-token)" \ https://coolify.lacompagniemaximus.com/api/v1/applications \ | python3 -c 'import sys,json for a in json.load(sys.stdin): print(a["name"], "auto_deploy=", a.get("auto_deploy"))' ``` ## Decisions retenues (resolues via /analyze 2026-05-09) - **Portee** : fix isole sur `vps-health-api` (~10 min). Audit cross-app -> issue umbrella separee dans `la-compagnie-maximus` si drift detecte sur 2+ apps - **Repo** : issue reste dans `vps-health-api` (regression observee ici, contexte produit ici, meme si fix touche config externe) - **Token deploy** : hors scope. Le webhook server-to-server n'a pas besoin de token API. Mention dans `coolify-ops.md` que `~/.coolify-token` actuel est read/write only - **Doc CLAUDE.md** : pas de modification (phrase actuelle redevient vraie post-fix) ## Acceptation - [ ] Webhook Forgejo actif sur `maximus/vps-health-api` (events `push` sur `main`) - [ ] `auto_deploy=true` sur l'app Coolify - [ ] Test E2E : merge d'une PR triviale -> redeploy automatique observable dans Coolify dans la minute - [ ] Audit cross-app fait, resultat documente en commentaire de cette issue, umbrella creee si drift detecte - [ ] Doc `coolify-ops.md` a jour si la procedure a revele un gotcha ## Surface de test Pas de tests unitaires (config infra). Test de regression = test E2E ci-dessus (merge PR triviale -> redeploy auto). ## Complexite **Simple** — config infra hors code, ~10 min si la source Coolify est compatible webhook. Sinon **Medium** (re-provisioning source).

maximus added the

source:human

status:ready

labels 2026-05-08 01:37:25 +00:00

maximus added the

type:infra

label 2026-05-09 21:20:40 +00:00

maximus commented

2026-05-10 20:36:19 +00:00

Author

Owner

Rolled into umbrella issue maximus/la-compagnie-maximus#133.

Le diagnostic de fix-issue 2026-05-10 a revele que les 4 apps Coolify (vps-health-api, maximus-api, denicheurs-web, denicheurs-worker) ont le meme drift auto_deploy=None + source_id=None. Le fix necessite de configurer une integration Source Forgejo dans Coolify (chantier UI, pas API) et de migrer chaque app — pas un fix isole sur cette app.

Fermeture en rolled-into pour eviter de jeter le travail au prochain re-provisioning.

Rolled into umbrella issue [maximus/la-compagnie-maximus#133](https://git.lacompagniemaximus.com/maximus/la-compagnie-maximus/issues/133). Le diagnostic de fix-issue 2026-05-10 a revele que les 4 apps Coolify (`vps-health-api`, `maximus-api`, `denicheurs-web`, `denicheurs-worker`) ont le meme drift `auto_deploy=None` + `source_id=None`. Le fix necessite de configurer une integration Source Forgejo dans Coolify (chantier UI, pas API) et de migrer chaque app — pas un fix isole sur cette app. Fermeture en rolled-into pour eviter de jeter le travail au prochain re-provisioning.

maximus closed this issue

2026-05-10 20:36:19 +00:00

maximus referenced this issue

2026-05-13 00:50:35 +00:00

feat: route GET /defenseurs/findings?project=X #3