GitFlow Guardian AI

• 

  frontend

• 

  session reset

• 

  discussion

Inspiration

On voit souvent les mêmes erreurs dans les équipes Git: des pushes sur main, des messages de commit trop vagues, des TODO/FIXME/debug qui passent en MR, et des merges qui finissent avec des conflits. J’ai voulu construire un “teammate” autonome pour GitLab: il réagit aux events (push / merge request) et aide à prévenir ces problèmes avant qu’ils causent du retard.

What it does

Un agent “GitFlow Guardian” basé sur Python + FastAPI Un serveur qui reçoit les webhooks GitLab sur POST /webhook Des handlers qui: valident les pushes (branches, qualité commit, TODO/debug, heuristiques secrets) assistent les Merge Requests (résumé, risques, reviewers, best practices) Un système d’idempotency (SQLite) pour éviter de traiter 2 fois le même event Une interface HTML (dans ton projet) pour tester localement: analyse du repo correction .gitignore workflow push guidé étape par étape (branche puis message commit)

How we built it

Python FastAPI (webhook + UI + routes) SQLite (idempotency store) GitLab REST API (comments/notes + commit status en MVP) LLM (Groq/OpenAI-compatible) pour résumé MR et suggestions de messages pytest pour la suite de tests

Challenges we ran into

Rendre l’agent fiable même quand l’API LLM/Groq a des erreurs: le backend doit toujours répondre en JSON, sinon l’UI casse. Normaliser les payloads GitLab: selon les events, project_id n’est pas toujours au même endroit. Permettre un “push tool” contrôlé (sans surprises): le bot ne push qu’après confirmation guidée. Gérer la sécurité: éviter de pousser des fichiers sensibles et ajouter automatiquement les règles .gitignore nécessaires (venv, .env, caches…).

Accomplishments that we're proud of

Un prototype complet “agent-like” qui réagit à des events et prend des actions réelles via des outils (FastAPI + handlers). Validation de push: règles de branche, détection TODO/FIXME/debug, warnings commit message, et commentaires sur GitLab (best-effort). Assistant Merge Request: résumé, scan de risques, suggestions reviewers, et note de best practices directement dans le MR. Interface web (HTML) pour tester localement le workflow: analyse, réparation .gitignore, et push guidé en étapes (branche puis message commit). Système d’idempotence SQLite pour éviter de traiter deux fois le même webhook.

What we learned

Un “agent” doit être fiable: si le backend crash ou renvoie du non-JSON, l’UI casse vite. D’où la robustesse ajoutée sur /chat. Les webhooks GitLab ont des payloads variables; normaliser project_id est crucial pour éviter des “skipped”. Pour réduire les erreurs, il faut gater les actions (ex: push seulement après confirmation guidée). L’importance d’une boucle feedback claire: l’agent doit expliquer le “pourquoi” et proposer la “next step”.

What's next for GitFlow Guardian AI

Déploiement “vrai” (sur une URL publique) pour recevoir les webhooks GitLab sans simulation (ex: Cloud Run / VM / tunnel). Ajout de politiques plus strictes côté CI (commit status plus robuste, gating sur branches protégées). Orchestration multi-agents (flow) : security scan → MR notes → test hints → amélioration commit → merge assistance. Enrichir la détection de conflits (quand possible via sandbox/simulations plus poussées) sans faire de résolution auto non désirée. Génération de tests uniquement quand on a une base claire (MVP déjà respecté: on reste “basic” au début).

Built With

• api
• fastapi
• gitlab
• llm
• pytest
• python
• rest
• sqlite