Connecter Semaphore à vos outils

Utilisez une intégration webhook lorsqu’un événement externe doit sélectionner un Task Template prédéfini et associer les valeurs reçues aux entrées acceptées. Utilisez la REST API si l’application nécessite un parcours explicite de ressources et d’exécution, comme lancer une tâche puis lire son état. Dans les deux cas, l’automatisation suit le modèle configuré de Semaphore. Choisissez selon ce que l’appelant doit envoyer et suivre.

Un alias de projet évalue les règles de correspondance configurées dans ses intégrations et peut démarrer celles qui correspondent à la requête. Un alias propre à une intégration cible directement celle-ci sans évaluer ses règles. Cette distinction est importante si une règle de branche ou de type d’événement doit contrôler l’exécution. Choisissez le point de terminaison délibérément et testez les données correspondantes et non correspondantes, au lieu de supposer que le même filtre s’applique à tous les chemins d’alias.

Configurez les extracteurs pour lire les en-têtes ou champs de contenu pertinents et les associer aux valeurs d’environnement ou paramètres de tâche documentés. Les destinations des paramètres doivent correspondre aux champs acceptés par le modèle. Gardez une correspondance précise : une version de release doit devenir l’entrée prévue, pas un fragment de commande sans restriction. Validez la valeur dans votre automatisation lorsque sa signification l’exige et testez les champs manquants ou inattendus avant la production.

Un jeton API agit avec les autorisations de son utilisateur Semaphore. Utilisez une identité dont l’accès aux projets correspond aux opérations prévues et protégez le jeton là où l’appelant le stocke. L’API ne contourne pas les autorisations des projets. Pour les intégrations webhook, configurez aussi délibérément l’authentification documentée des requêtes et l’exposition du point de terminaison. Séparez l’authentification de l’appelant des identifiants utilisés par la tâche pour joindre l’infrastructure.

Pour un parcours REST API, conservez l’identifiant de tâche renvoyé par l’opération documentée et utilisez les méthodes API correspondantes pour examiner état et sortie. Une requête réussie signifie que l’exécution a été demandée, pas que le travail d’infrastructure a réussi. Votre service doit distinguer erreurs de requête, tâches en attente ou en cours et résultats terminés. Orientez les ingénieurs vers la tâche lorsqu’ils doivent examiner les preuves réelles de l’exécution.

Ne supposez ni exécution exactement une fois ni garantie de livraison durable. Un service externe peut réessayer une requête après un délai dépassé, même si la première a atteint Semaphore. Concevez la gestion des doublons et les décisions de nouvelle tentative selon les conséquences de l’opération et rendez l’automatisation sous-jacente idempotente lorsque c’est approprié. Conservez la correspondance entre l’événement d’origine et l’exécution suivie par votre service pour comprendre les livraisons répétées ou incertaines.

La référence de ce site affiche le document Swagger/OpenAPI publié avec la version Semaphore. Opérations, chemins et schémas correspondent donc à une version précise plutôt qu’à un résumé manuel. Parcourez-le par ressource dans /api-docs/ ou lisez le document brut pour générer un client. Vérifiez toujours la spécification de votre version réelle, car points de terminaison et schémas peuvent changer entre versions.

Le système appelant doit joindre votre instance Semaphore, mais pas nécessairement via Internet public. Réseau privé, VPN ou répartiteur interne suffisent si l’appelant s’y trouve. Nos tests de correspondances et extracteurs utilisaient un point d’écoute limité au loopback sans authentification, ce qui n’est pas un modèle pour un point exposé. Dès que l’alias est accessible hors du réseau de confiance, configurez une méthode d’authentification prise en charge et limitez aussi son exposition au niveau réseau.

Ciblez d’abord un Task Template sans danger, puis envoyez vous-même les données avec curl ou un client HTTP. Envoyez un contenu non correspondant et vérifiez qu’aucune tâche n’apparaît, puis un contenu correspondant et vérifiez qu’une seule tâche démarre. Ouvrez sa vue Details : elle indique l’intégration comme source et les valeurs extraites sont accessibles à l’exécution. Nous avons utilisé cette même séquence localement ; elle détecte une mauvaise clé de correspondance avant qu’un service externe en dépende.

Oui. La REST API couvre projets, dépôts, inventaires, identifiants, Variable Groups, Task Templates et autres ressources. Votre portail ou service peut les configurer, lancer des tâches et lire état et sortie. Pro expose aussi exécutions et approbations de workflows pour qu’une pipeline CI/CD lance une opération complète à plusieurs étapes. Consultez la référence OpenAPI pour paramètres et schémas de réponse.