Validateur de noms de branches git

Les noms vides échouent avec invalid_input, tout comme les caractères de ref git peu sûrs courants : espaces, points consécutifs et ponctuation interdite.

Fonctionnement du motif de convention et extractions

Si la branche ne correspond pas au motif entier, la tâche échoue avec invalid_input et un message qui cite la branche et la convention pour que les développeurs corrigent le nom ou la politique d’un seul coup d’œil.

Contrat d’entrée, contrôles de sécurité et forme de la réponse

Les caractères de contrôle sont aussi rejetés. Les clés de sortie optionnelles sont omises plutôt que mises à null. L’échec de validation n’est pas facturé. Associez la réponse à votre propre couche de politique si vous avez besoin d’une liste autorisée de valeurs de type comme feature, fix, chore ou release ; cette capacité vérifie la structure et extrait les parties, elle ne code pas en dur le vocabulaire d’une seule organisation. Envoyez en POST un corps JSON avec deux chaînes obligatoires : branch, le nom candidat de la branche git, et convention, le modèle de nommage. Des alias sont acceptés pour la commodité—branch_name, name et ref pour le champ branche ; pattern, format et template pour le champ convention—mais les noms canoniques figurent dans la documentation et les SDK. Les deux champs doivent être non vides après rejet des seuls espaces ; une branche vide est toujours invalid_input car git ne peut pas créer une ref de longueur nulle et l’automatisation qui oublie de passer le nom doit échouer de façon fermée. En cas de succès le corps inclut valid true, la branche et la convention renvoyées en écho, un objet components associant chaque nom de placeholder à sa valeur capturée, component_names dans l’ordre du modèle et component_count.

Où un validateur de noms de branches apporte de la valeur

Les jobs d’intégration continue utilisent un validateur de convention de noms de branches git comme première étape d’un pipeline afin que les pull requests ouvertes avec des noms ad hoc n’atteignent jamais les étapes de build coûteuses. L’automatisation de release extrait le composant ticket pour ouvrir ou mettre à jour des tickets du tracker, et extrait le composant type pour choisir les sections du changelog sans hacks fragiles de sous-chaînes. Les sites de contenu qui se positionnent sur validateur de convention de noms de branches git bénéficient d’un formulaire en direct dont le chemin gratuit correspond octet par octet au chemin d’automatisation payant. Les équipes plateforme qui gèrent de nombreux dépôts publient une seule chaîne de convention dans leur portail développeur et pointent chaque modèle, bot et checklist vers cet endpoint, de sorte qu’un changement de politique soit une seule édition de chaîne plutôt qu’une chasse dans des scripts shell. Comme l’implémentation est pure parse de niveau A, chaque appel réussi coûte le prix de base publié $0.002 sans tokens de modèle et sans réseau sortant.