GitLab

GitLab

Intégration maintenue par Orkyvo (non certifiée par GitLab Inc.) pour GitLab.com et les instances autohébergées (CE / EE, API REST v4, GitLab 15 ou ultérieur recommandé).

Connexion

Permissions nécessaires (principe du moindre privilège)

• Lecture seule (lister, obtenir) : portée read_api, rôle *Reporter*.
• Tickets, commentaires, merge requests, déclenchement de pipeline : portée api, rôle *Developer*.
• Déclencheurs (création automatique du webhook de projet) : portée api, rôle *Maintainer* sur le projet.
• Préférez un jeton de projet ou un compte de service dédié à Orkyvo, avec une date d'expiration.

« Tester la connexion » lit uniquement GET /user, GET /version et GET /personal_access_tokens/self (portées et expiration du jeton) : aucune écriture.

Instance privée

Une instance sur un réseau privé (ex. 10.20.0.15) est refusée par défaut. Un administrateur de la plateforme peut autoriser la plage d'adresses et le port pour cette organisation et cette connexion uniquement (Administration → Réseaux privés). La boucle locale, les adresses de lien local et les points de métadonnées cloud restent toujours refusés ; chaque redirection est revérifiée.

Actions

Le projet accepte l'identifiant numérique ou le chemin complet groupe/sous-groupe/projet : il est encodé (groupe%2Fprojet), jamais interprété comme des segments d'URL. Le sélecteur propose vos projets (recherche) ; la saisie manuelle et les données des étapes précédentes ({{ $json.project }}) restent possibles.

Pas de relance aveugle : une création (ticket, merge request, pipeline) n'est jamais relancée automatiquement après une réponse réseau perdue ; l'étape échoue avec « Résultat incertain » pour que vous vérifiiez dans GitLab. Les lectures sont relancées sur 429 / 502 / 503 / 504 en respectant Retry-After.

Déclencheurs

Fonctionnement :

1. À la publication du workflow, Orkyvo crée un webhook sur le projet (POST /projects/:id/hooks) avec l'URL du workflow et un jeton secret aléatoire, vérification TLS activée.
2. Chaque appel est authentifié : l'en-tête X-Gitlab-Token est comparé au secret (comparaison à temps constant). Ce secret n'est jamais enregistré dans l'historique des exécutions.
3. Les livraisons répétées (nouvelles tentatives de GitLab, renvois manuels) sont dédoublonnées par une clé stable dérivée de l'événement (ex. identifiant du pipeline + statut).
4. Les événements filtrés sont ignorés sans exécution ni décompte.
5. À la désactivation, le webhook est supprimé de GitLab ; une republication identique réutilise le webhook existant.

Prérequis : le serveur GitLab doit pouvoir joindre l'URL publique d'Orkyvo en HTTPS (pare-feu sortant de l'instance autohébergée).

Exemple de sortie (statut de pipeline)

{
  "project": { "id": 1234, "path_with_namespace": "acme/api" },
  "pipeline": { "id": 88001, "status": "failed", "ref": "main", "url": "https://gitlab.example.com/acme/api/-/pipelines/88001" },
  "failedJobs": [{ "id": 9001, "name": "test:unit", "stage": "test", "failureReason": "script_failure" }]
}

Erreurs

Limites

• 500 projets au plus par liste, 200 jobs au plus par pipeline.
• Les tests automatisés du nœud utilisent des réponses simulées ; voir docs/INTEGRATIONS.md pour la procédure de test réel sur une instance dédiée.