Aller au contenu

GitLab — intégration CI vers SIRRAT (notify / déploiement)

Ce document décrit ce qui doit exister côté Git / GitLab pour qu’un pipeline puisse notifier SIRRAT après build (image registry, artefact prêt) ou déclarer un déploiement. SIRRAT ne build pas à la place de GitLab CI : il reçoit des signaux, applique les quality gates et trace les promotions.

Voir aussi le concept produit : SIRRAT — Quality Gates & PV Recette.

1. Principe de séparation

Responsabilité Où ça vit
Compiler, tester, scanner, pousser image/registry GitLab CI (.gitlab-ci.yml)
Enregistrer projet, gates, PV, décisions de promotion SIRRAT (API + UI), base SIRRAT
Secrets machine-to-machine CI → SIRRAT GitLab CI/CD Variables (ou Vault → injecté en CI), jamais dans Git
Description métier des environnements / gates par produit SIRRAT Forge (templates) + instance SIRRAT — pas de sirrat.config.yml dans le repo app (legacy)

2. Ce qui doit être versionné dans Git (sans secrets)

  • .gitlab-ci.yml
  • Stages habituels : lint → build → test → publish → notify (ou équivalent).
  • Job(s) qui appellent l’API SIRRAT après succès du publish (ou en parallèle selon le modèle).

  • Garde-fous : allow_failure: true sur la notif si l’artefact est déjà sûr côté registry (éviter pipeline rouge uniquement si SIRRAT est injoignable).

  • Documentation du PROJECT_ID / code app

  • Les pipelines satellites passent souvent un identifiant métier (ex. dawalale-001) ou un appCode attendu par SIRRAT. Ces valeurs sont non secrets et peuvent être dans .gitlab-ci.yml ou dans des variables CI non protégées.

  • Déclaration SIRRAT Forge (hors repo app)

  • Gates, cercles, URLs couloir SLY et secrets résolus via templates — pas de sirrat.config.yml dans le repo satellite. Voir SIRRAT — concept.

3. Variables GitLab CI/CD (Settings → CI/CD → Variables)

À créer au niveau projet (ou groupe), masquées, protégées si uniquement branches protégées :

Variable Usage typique Remarques
SIRRAT_API_TOKEN Auth Bearer ou équivalent selon le template Token machine dédié ; rotation via ops ; scope minimal (notifier / enregistrer déploiement).
SIRRAT_API_URL ou SIRRAT_URL Base URL de l’API SIRRAT Ex. https://staging.dynors.com/sirrat/api vs https://sirrat.dynors.com — aligner le chemin avec le job (/artifact-ready vs /api/v1/...).
GITLAB_TOKEN / CI_JOB_TOKEN Accès Package Registry com.dynors.* Distinct de SIRRAT ; souvent déjà requis pour le build.

Si SIRRAT_API_TOKEN ou l’URL est absente : les jobs « notify » bien écrits journalisent et sortent en succès conditionnel (ou allow_failure: true) pour ne pas bloquer la livraison registry.

Réseau : l’hôte dans SIRRAT_* doit être joignable depuis les runners qui exécutent le job (runners SaaS GitLab.com = Internet public ; DNS/TLS/firewall). Une erreur curl exit 6 indique souvent un problème DNS / connectivité, pas un 401/403.

4. Deux familles de callbacks CI (à harmoniser par dépôt)

Les dépôts DYNORS n’ont pas tous encore le même template. Vérifier le contrat exact du SIRRAT déployé avant de copier-coller un job.

Variante A — Satellites (ex. DAWALALE)

  • Méthode : POST ${SIRRAT_API_URL}/artifact-ready
  • En-tête : Authorization: Bearer ${SIRRAT_API_TOKEN}
  • ** Corps** : JSON avec projectId, version, imageUrl, commitSha, branch, etc.

Variante B — Internal / modèle ADR (POST déploiement)

  • Méthode : POST ${SIRRAT_URL}/api/v1/deployments
  • En-tête : X-Sirrat-Token: ${SIRRAT_API_TOKEN}
  • Corps : JSON avec app, env, version, status, commitSha, pipeline, …

Action recommandée : converger les nouveaux pipelines vers une seule convention documentée dans l’OpenAPI / README du backend sirrat (dynors-internal), puis mettre à jour les .gitlab-ci.yml historiques.

5. Runners GitLab

  • Les jobs sans tag utilisent les runners partagés GitLab.com (sous quota du namespace).
  • Si vous utilisez des tags (ex. dynors-runner), chaque projet doit avoir des runners en ligne avec ce tag, sinon les jobs restent pending.
  • Détails : Environnements & CI/CD.

6. Checklist — nouveau satellite ou nouveau dépôt

  1. Créer / adapter .gitlab-ci.yml (build, test, publish image si applicable).
  2. Ajouter le job notify SIRRAT (ou équivalent) avec gestion d’erreur réseau et, si besoin, allow_failure: true.
  3. Déclarer les variables SIRRAT_API_URL / SIRRAT_URL et SIRRAT_API_TOKEN dans GitLab (pas dans le repo).
  4. Enregistrer le projet dans SIRRAT avec le bon projectId / appCode attendu par le JSON du pipeline.
  5. Tester depuis un runner réel : pas seulement en local (DNS/firewall différent).
  6. Déclarer l'app dans SIRRAT Forge (templates, gates) — sans sirrat.config.yml dans le repo.

7. Références internes workspace (clone complet)

  • Vision / sécurité ops : docs/architecture/SIRRAT_CONTROL_PLANE_VISION_2026-04-27.md, docs/architecture/ADR-SIRRAT-SECURITE-OPS-DEDIEE_2026-04-28.md
  • Contrat CI détaillé (exemple template) : docs/architecture/ADR_SPEC_AGENT_INTERNAL_RUNTIME.md (§ notify / déploiements)
  • Produit SIRRAT (README) : docs/projet-nouveau/SIRRAT/README.md
  • Runbook court (lien stable dans le repo workspace) : docs/runbooks/GITLAB_SIRRAT_CI_INTEGRATION.md