TL;DR en langage simple
- CI‑medic est un projet open‑source pour trier automatiquement les échecs CI (CI = intégration continue). Il se décrit comme « AI triage for failed CI runs », privacy‑first et vendor‑agnostic (https://github.com/alitariq4589/ci-medic).
- Ce que vous obtenez rapidement : un résumé court des échecs, des suggestions actionnables et une aide à l'attribution (qui doit réparer).
- Avantage principal : moins de temps perdu à lire des logs longs. Respect de la confidentialité si vous hébergez localement.
Actions immédiates (3 étapes simples) :
- [ ] Cloner le dépôt et lire le README : https://github.com/alitariq4589/ci-medic
- [ ] Déployer une instance de test en lecture seule
- [ ] Lancer un job qui échoue et envoyer son payload pour triage
Exemple rapide (scenario concret) : Vous êtes une petite équipe. Un pipeline de test échoue après une mise à jour de dépendance. Vous envoyez l'extrait de log à CI‑medic. L'outil renvoie un résumé du type : "Échec lié à la version X de la lib Y, test Z en timeout" et propose qui assigner. Vous gagnez 15–30 minutes par incident.
git clone https://github.com/alitariq4589/ci-medic.git
cd ci-medic
Méthodologie : guide basé principalement sur le README du dépôt https://github.com/alitariq4589/ci-medic.
Ce que vous allez construire et pourquoi c'est utile
Vous allez déployer un service qui aide à diagnostiquer automatiquement les runs CI échoués. Le dépôt se décrit comme un outil d'AI triage pour échecs CI et insiste sur la confidentialité et l'indépendance vis‑à‑vis des fournisseurs (https://github.com/alitariq4589/ci-medic).
Bénéfices attendus :
- Diminution du temps de triage.
- Assignation plus rapide du bon responsable.
- Suggestions répétables pour corriger des erreurs fréquentes.
Comparatif de modes de déploiement :
| Option | Avantage principal | Inconvénient principal | |---------|-------------------------------|-------------------------------| | Local | Confidentialité maximale | Coût infra + maintenance | | API | Démarrage très rapide | Données envoyées hors site | | Hybride | Compromis entre les deux | Complexité d'architecture |
Source : https://github.com/alitariq4589/ci-medic
Avant de commencer (temps, cout, prerequis)
Source principale : https://github.com/alitariq4589/ci-medic
Prérequis courts :
- Accès Git et droits pour cloner le repo.
- Connaissance basique du CI (ex. GitHub Actions, GitLab CI).
- Un endpoint HTTP pour recevoir POST (local ou cloud).
Estimations temporelles et coûts (orientations) :
- POC minimal : 60–120 minutes.
- Canary initiale : 50–100 échecs sur 1–2 semaines.
- Revue quotidienne : 30–60 minutes pendant la phase d'observation.
- Coût logiciel : 0 $ pour le code (open‑source). Les coûts opérationnels varient selon hébergement ou API.
Checklist préparation :
- [ ] Cloner https://github.com/alitariq4589/ci-medic
- [ ] Choisir mode backend (local / API / hybride)
- [ ] Préparer un endpoint pour recevoir les payloads
Installation et implementation pas a pas
Source : https://github.com/alitariq4589/ci-medic
- Récupérer le code
git clone https://github.com/alitariq4589/ci-medic.git
cd ci-medic
ls -la
- Exemple de test d'envoi (curl)
curl -X POST "https://ci-medic.example/internal/triage" \
-H "Authorization: Bearer REPLACE_ME" \
-H "Content-Type: application/json" \
-d '{"ci":"github_actions","workflow":"test","status":"failed","logs":"..."}'
- Config minimale (exemple à adapter)
# configuration d'exemple (valeurs à valider)
service:
mode: "test" # test | production
port: 8080
model:
timeout_ms: 10000
max_tokens: 2048
redaction:
enabled: true
max_chars: 5000
- Processus d'itération
- Lancer un petit nombre d'échecs (ex. 10–50) en canary.
- Mesurer latence cible (ex. <= 10 000 ms) et taux d'acceptation initial (objectif >= 60%).
Note : adaptez timeouts et tailles d'extraits selon sensibilité des logs et budget.
Explication simple avant détails avancés
En clair : vous fournissez au service un extrait de log et des métadonnées du run CI. Le service retourne un résumé, des causes possibles et des actions recommandées. Vous pouvez démarrer en lecture seule pour vérifier la qualité des suggestions. Si la précision est suffisante, vous pouvez ensuite automatiser certaines actions.
Ne vous inquiétez pas des détails techniques au départ. Commencez par envoyer quelques échecs et regardez les résultats. Ajustez la taille des extraits et la redaction pour protéger les données sensibles.
Problemes frequents et correctifs rapides
Source : https://github.com/alitariq4589/ci-medic
Symptômes fréquents et actions immédiates :
- Le service ne répond pas
- Vérifier que le processus écoute (port 8080 ou port configuré).
- Confirmer le secret webhook et les règles réseau.
- Triage peu pertinent
- Réduire la taille des extraits envoyés à 1 000–5 000 caractères.
- Ajouter un cycle de feedback humain et ajuster les prompts.
- Risque de fuite de données
- Activer la redaction et appliquer regex pour masquer tokens.
Règles rapides :
- Timeout modèle recommandé : 10 000 ms.
- Taille d'extrait conseillée en phase POC : 1 000–5 000 caractères.
- Canary initiale : 50 échecs; évoluer vers 500+ avant automatisation complète.
Checklist dépannage :
- [ ] Service démarré et reachable
- [ ] Secret webhook correct
- [ ] Backend modèle accessible
- [ ] Redaction activée si nécessaire
Premier cas d'usage pour une petite equipe
Source : https://github.com/alitariq4589/ci-medic
Contexte ciblé : fondateurs solo ou équipes de 2–5 personnes qui veulent réduire le temps perdu sur le triage CI.
Conseils concrets :
- Démarrage rapide en lecture seule
- Déployez en lecture seule d'abord (0 modifications automatiques).
- Produisez des rapports ou issues mais n'appliquez pas de correctifs automatiques.
- Durée recommandée : 7–14 jours de collecte.
- Budget et contraintes techniques
- Utilisez une API tierce pour démarrer si vous avez < 2 heures d'ingénierie disponible.
- Limitez la taille des extraits à 1 000–2 000 caractères pour réduire coût et risque.
- Fixez un timeout par appel à 10 000 ms pour ne pas bloquer vos pipelines.
- Boucle de feedback simple et KPI
- Chaque jour, passez 30–60 minutes à valider 10–20 suggestions.
- Si l'acceptation atteint >= 60% sur 50–100 cas, activez des actions automatisées sur 10% des dépôts.
- Automatisation progressive
- Phase 0 (0–2 jours) : read‑only + collecte (50 échecs).
- Phase 1 (1–2 semaines) : canary sur 10% des dépôts.
- Phase 2 (1–3 mois) : rollout par paliers et monitoring.
Checklist pour fondateur solo / petite équipe :
- [ ] Déployer en lecture seule
- [ ] Collecter 50–100 échecs
- [ ] Valider >= 60% d'acceptation avant automation
Notes techniques (optionnel)
Source : https://github.com/alitariq4589/ci-medic
Points techniques utiles à garder en tête :
- Normalisation des payloads CI pour rester vendor‑agnostic.
- Redaction par regex pour masquer clés, tokens et emails.
- Enregistrement de métriques : latence (ms), suggestions acceptées / totales (counts), coût par 1 000 requêtes ($).
Exemple de mapping JSON simplifié :
{
"ci": "github_actions",
"repo": "org/repo",
"run_id": 12345,
"logs_snippet": "...",
"timestamp_ms": 1710000000000
}
Mesures recommandées :
- Latence cible : <= 10 000 ms.
- Objectif d'acceptation pour automatiser : >= 60%.
- Rétention des échantillons POC : 7 jours.
Que faire ensuite (checklist production)
Hypotheses / inconnues
- Le dépôt se présente comme « AI triage for failed CI runs » et « privacy‑first, vendor‑agnostic » (https://github.com/alitariq4589/ci-medic).
- Les valeurs numériques (timeouts, tailles d'extraits, seuils d'acceptation) sont des recommandations pratiques à valider en POC : timeout = 10 000 ms, extrait = 1 000–5 000 caractères, canary = 50–100 échecs, seuil d'automatisation = 60%.
- La structure exacte des fichiers de config et des endpoints internes doit être confirmée dans le README du dépôt.
Risques / mitigations
- Risque : exposition de données sensibles.
- Mitigation : activer redaction, limiter extraits à 5 000 chars, héberger localement si nécessaire.
- Risque : suggestions incorrectes qui provoquent régressions.
- Mitigation : démarrer en lecture seule; n'automatiser qu'après atteinte du seuil (>= 60%).
- Risque : coûts d'API trop élevés.
- Mitigation : fixer budget mensuel, limiter appels à 1 000–5 000 requêtes/mois en phase POC.
Prochaines etapes
Court terme (0–2 jours)
- [ ] Cloner https://github.com/alitariq4589/ci-medic et créer une config minimale.
- [ ] Tester un POST de triage avec 1–5 échecs.
Moyen terme (1–2 semaines)
- [ ] Lancer une canary (50–100 échecs).
- [ ] Mesurer latence et taux d'acceptation; viser >= 60%.
Long terme (1–3 mois)
- [ ] Ajouter dashboards (latence ms, précision % , coût $).
- [ ] Formaliser retention (ex. 7 jours) et politiques de confidentialité.
Checklist finale production :
- [ ] Audit de confidentialité et redaction en place
- [ ] Monitoring et alertes configurés (latence, taux d'erreur, acceptance)
- [ ] Rollout gates et plan de rollback documentés
- [ ] Versioning de config et changelog actifs
Référence principale : https://github.com/alitariq4589/ci-medic