Paramètres et administration du service Git

  • Publié le May 22, 2026
  • 9 Minute(s) lue(s)
Prev Next

En tant qu'administrateur de projet ou du service Git, vous pouvez configurer chaque dépôt Git : branche par défaut, permissions d'accès, notifications, webhooks et options avancées. Ces paramètres sont accessibles via le bouton "Paramètres" dans le fil d'Ariane de la page d'un dépôt.

Configuration générale

L'onglet "Configuration générale" regroupe les paramètres fondamentaux du dépôt.

Description

Un champ Description vous permet d'ajouter un texte descriptif au dépôt. Cette description est affichée dans la liste des dépôts du projet et sur la page de navigation du dépôt. Ce champ est notamment utile pour préciser le rôle ou le contenu du dépôt (ex : "API backend du projet", "Documentation technique").

Branche par défaut

Dans un dépôt avec plusieurs branches, vous pouvez choisir la branche par défaut. La branche sélectionnée :

  • Est affichée lorsque les utilisateurs ouvrent le dépôt via l'interface web.

  • Est utilisée lors du clone du dépôt.

  • Ne peut pas être supprimée.

  • Est la branche prise en compte pour la fermeture automatique d'Artifacts via les messages de commit.

Autoriser la fermeture des artifacts

La case "Autoriser la fermeture des artifacts" active la possibilité de fermer automatiquement un Artifact de vos Trackers en le référençant dans un message de commit Git avec un mot-clé de fermeture (voir la section Fermeture automatique d'Artifacts pour le détail complet).

Permissions et contrôle d'accès

L'onglet "Permissions" permet de gérer qui peut lire, écrire et administrer le dépôt.

Permissions de base

Par défaut, un dépôt est lisible par tous les utilisateurs actifs de la plateforme, mais seuls les membres du projet peuvent le modifier. Vous pouvez ajuster les permissions par groupes d'utilisateurs pour trois niveaux :

  • Lecture : accès en lecture au dépôt (clone, fetch).

  • Ecriture : pousse de contenu dans le dépôt (commits, nouvelles branches, etc.).

  • Rewind : suppression de références (branches, tags) et réécriture complète de l'historique.

Permissions fines (Fine-grained permissions)

Pour un contrôle plus précis, vous pouvez gérer les permissions branche par branche et tag par tag.

  1. Activez les fine-grained permissions dans les paramètres du dépôt, puis sauvegardez.

  2. Définissez des patterns pour les branches et tags (par exemple refs/heads/main, refs/tags/v*).

  3. Attribuez les permissions par groupes d'utilisateurs pour chaque pattern.

Builds CI (Commit Status)

L'onglet "Builds CI" permet de configurer les statuts de build associés aux commits.

Tuleap permet d'associer un statut de build CI à un commit Git. Ce statut est affiché sous forme de badge sur les commits dans l'interface web et sur les Pull Requests.

Un système de CI (Jenkins, GitLab CI, etc.) peut envoyer le résultat d'un build à Tuleap via l'API REST :

POST /api/git/{id}/statuses/{commit_reference}

Le paramètre state accepte les valeurs : success, failure ou pending.

Par défaut, tout utilisateur ayant la permission d'écriture peut envoyer un statut de build. Depuis cet onglet, vous pouvez restreindre cette capacité à des groupes d'utilisateurs spécifiques, afin de limiter le déclenchement aux seuls systèmes CI autorisés.

Information

Le plugin Tuleap API pour Jenkins gère automatiquement l'envoi du statut de build. Si vous utilisez un autre système CI, vous devez implémenter l'appel REST manuellement.

Notifications email

L'onglet "Notifications" permet de configurer le dépôt pour envoyer un email à chaque push. Cette notification permet à toute l'équipe de rester informée des modifications apportées au code.

Vous pouvez personnaliser :

  • Le préfixe du sujet : un texte ajouté au début de l'objet de chaque email de notification (par exemple [MonProjet]).

  • La liste des destinataires : utilisateurs Tuleap, groupes d'utilisateurs, ou adresses email libres (comme une liste de diffusion).

Le contenu de l'email inclut :

  • La liste des commits poussés dans le dépôt.

  • Les fichiers modifiés (avec des diffstats).

  • Pour chaque commit, un lien vers le diff dans l'interface web Tuleap.

  • Pour chaque référence détectée dans la description du commit, le lien automatique correspondant vers l'Artifact.

Information

L'extraction des références croisées dans les messages de commit ne fonctionne que si la notification email est configurée.

Webhooks

L’onglet “Webhooks” permet de configurer votre dépôt pour qu'à chaque push, un endpoint HTTP soit appelé.

Webhooks personnalisés (Custom Webhooks)

Les webhooks personnalisés envoient un appel HTTP POST à l'URL de votre choix à chaque push. Le payload contient les informations sur le push (références mises à jour, auteur, commits).

Information

Pour plus de détails sur le format du payload, consultez la section Webhook Git de la documentation technique.

Webhooks Jenkins

Un webhook Jenkins notifie votre instance Jenkins à chaque push. Pour le configurer :

  1. Accédez aux paramètres du dépôt, section Webhooks.

  2. Ajoutez un webhook Jenkins en fournissant l'URL de votre instance Jenkins et le notifyCommit access token (généré depuis la page Global Security de Jenkins).

Vous pouvez créer un webhook Jenkins par dépôt. Au niveau des paramètres du service Git du projet, vous pouvez également ajouter des webhooks Jenkins qui seront déclenchés pour tous les dépôts du projet.

Le journal des jobs déclenchés est visible dans la section Historique du webhook.

Note d’utilisation

Le plugin hudson_git doit être installé sur votre instance Tuleap pour créer des webhooks Jenkins.

Webhooks Jenkins pour Tuleap Branch Source

Cette fonctionnalité permet une intégration complète et automatisée avec Jenkins via le plugin Jenkins Tuleap Git Branch Source. Jenkins découvre automatiquement les dépôts, branches et Pull Requests de votre projet.

Information

La configuration détaillée est décrite dans la documentation Tuleap Git / Jenkins integration.

Onglet Supprimer

L'onglet "Supprimer" permet de supprimer le dépôt Git du projet.

Procédure

  1. Accédez à l'onglet Supprimer dans les paramètres du dépôt.

  2. Cliquez sur le bouton "Supprimer ce dépôt" (rouge).

Attention

La suppression est irréversible depuis l'interface projet. Toutes les données associées (branches, tags, historique, Pull Requests) seront perdues.

Si le dépôt est connecté à un serveur Gerrit, il doit d'abord être déconnecté avant de pouvoir être supprimé. Le message suivant s'affiche : "Le dépôt ne peut être supprimé avant d'être déconnecté de Gerrit".

Un administrateur de la plateforme peut consulter les "Dépôts git supprimés" dans l'administration du site et restaurer un dépôt supprimé, à condition qu'un dépôt portant le même nom n'existe pas déjà dans le projet.

Fonctionnalitées supplémentaires

Git LFS (Large File Storage)

Git ne gère pas efficacement les fichiers binaires volumineux (vidéos, images, fichiers audio). Git LFS résout ce problème en stockant ces fichiers séparément.

Note d’utilisation

Le plugin gitlfs doit être installé et activé pour utiliser Git LFS.

Information

Pour plus de détails, consultez le site officiel Git LFS et le wiki Git LFS.

Restrictions de taille de fichiers

Les fichiers de plus de 50 Mo sont automatiquement rejetés par Tuleap. Ces fichiers volumineux doivent être gérés via Git LFS.

Information

Un administrateur de la plateforme peut accorder une exception à votre projet. Consultez la section Increase max file size de la documentation technique.

Fermeture automatique d'Artifacts

Vous pouvez fermer un Artifact de vos Trackers en le référençant dans un message de commit Git avec un mot-clé de fermeture.

Pour utiliser cette fonction, activez l'option "Autoriser la fermeture des artifacts" dans la Configuration générale de votre dépôt.

Pour que la fermeture fonctionne, toutes ces conditions doivent être remplies :

  1. L'option "Autoriser la fermeture des artifacts" est activée sur le dépôt.

  2. Le commit est poussé sur la branche par défaut du dépôt.

  3. La référence a la forme <mot-clé de fermeture> <mot-clé de référence> #<id> (par exemple : Implements story #123 ou Fixes bug #456).

  4. L'Artifact référencé appartient au même projet que le dépôt Git.

  5. Le statut de l'Artifact n'est pas déjà fermé.

  6. La sémantique "Done" du Tracker est définie (sinon la sémantique "Status" doit avoir au moins une valeur "fermé").

  7. Le workflow du Tracker autorise la transition.

  8. Les dépendances de champs n'empêchent pas la fermeture.

Mots-clés de fermeture

Les mots-clés suivants (insensibles à la casse) peuvent être utilisés :

  • Closes / Close / Closed / Closing / chore:

  • Fixes / Fix / Fixed / Fixing / fix:

  • Implements / Implement / Implemented / Implementing / feat:

  • Resolves / Resolve / Resolved / Resolving

Exemples :

Closes art #123
fix: art #456
Implements story #789, Fixes bug #101

Lorsque toutes les conditions sont remplies, le statut de l'Artifact est changé à la première valeur valide de la sémantique "Done". La fermeture est effectuée par un bot Tuleap nommé "Tracker Workflow Manager" avec un commentaire de suivi expliquant la raison de la fermeture.

Astuce

Vous pouvez fermer plusieurs Artifacts à la fois dans un seul message de commit.

Créer une branche depuis un Artifact

Depuis Tuleap 13.11, vous pouvez créer une branche Git et la Pull Request associée directement depuis un Artifact de vos Trackers.

Note d’utilisation

Les plugins Git, Tracker et Pull Request doivent être installés. Des dépôts Git doivent exister dans le même projet que l'Artifact.

Procédure

  1. Ouvrez un Artifact dans un Tracker.

  2. Dans les actions de l'Artifact, sélectionnez "Créer une branche dans un dépôt Git".

  3. Dans la modale :

    • Sélectionnez un dépôt parmi les dépôts du projet (pas les forks personnels).

    • Choisissez la référence de base (branche par défaut proposée automatiquement, ou saisissez une autre branche / un SHA-1).

    • Un aperçu du nom de la branche est affiché. Le format est fixe : tuleap-{artifact_id}-{artifact-title}.

    • La case "Créer une pull request basée sur cette nouvelle branche" est cochée par défaut.

  4. Cliquez sur "Créer la branche".

Pre-receive Hook (Technology Preview)

Tuleap offre la possibilité d'exécuter des scripts personnalisés lors du hook pre-receive de Git. Ces scripts peuvent valider ou rejeter un push selon des règles métier.

Les scripts doivent être des modules WASM (WebAssembly) compilés avec le support WASI Preview 1.

Attention

Cette fonctionnalité est en Technology Preview et peut évoluer dans les versions futures.

Information

Pour les détails techniques (format d'entrée/sortie, limitations, installation), consultez la section Pre-receive hook de la documentation technique.

Statut de build (Commit Status)

Tuleap permet d'associer un statut de build CI à un commit Git. Ce statut est affiché sous forme de badge sur les commits dans l'interface web et sur les Pull Requests.

Fonctionnement

Un système de CI (Jenkins, GitLab CI, etc.) peut envoyer le résultat d'un build à Tuleap via l'API REST :

POST /api/git/{id}/statuses/{commit_reference}

Le paramètre state accepte les valeurs : success, failure ou pending.

Permissions

Par défaut, tout utilisateur ayant la permission d'écriture peut envoyer un statut de build. Vous pouvez restreindre cette capacité à des Access Keys spécifiques via l'administration du dépôt, afin de limiter le déclenchement aux seuls systèmes CI autorisés.

Info

Le plugin Jenkins Tuleap API pour Jenkins gère automatiquement l'envoi du statut de build. Si vous utilisez un autre système CI, vous devez implémenter l'appel REST manuellement.

Administration de Git au niveau du projet

En plus des paramètres par dépôt, le service Git propose une administration centralisée au niveau du projet. Cette page est accessible depuis le lien "Administration" dans le menu déroulant du fil d'Ariane "Dépôts Git".

La page d'administration est organisée en cinq onglets :

  • Modèles Gerrit : création et gestion de modèles de configuration de permissions Gerrit réutilisables (nécessite un serveur Gerrit configuré).

  • Administrateurs Git : gestion des groupes d'utilisateurs ayant le rôle d'administrateur du service Git.

  • Modèle des dépôts Git : permissions d'accès par défaut appliquées aux nouveaux dépôts.

  • Lien vers un groupe GitLab : configuration de l'intégration GitLab au niveau du projet (voir chapitre Intégration GitLab).

  • Jenkins : webhooks Jenkins appliqués à l'ensemble des dépôts du projet.

Administrateurs Git

Par défaut, les administrateurs du projet sont également administrateurs du service Git. Depuis l'onglet "Administrateurs Git", vous pouvez ajouter d'autres groupes d'utilisateurs comme administrateurs Git.

Un administrateur Git peut :

  • Créer, modifier et supprimer des dépôts.

  • Gérer les permissions de tous les dépôts.

  • Configurer les webhooks et les intégrations.

  • Accéder à la page d'administration de Git.

Modèle des dépôts Git

L'onglet "Modèle des dépôts Git" permet de définir des permissions d'accès par défaut qui seront automatiquement appliquées à chaque nouveau dépôt créé dans le projet.

  1. Accédez à l'onglet "Modèle des dépôts Git" dans l'administration de Git.

  2. Configurez les permissions Lecture, Écriture et Rewind par groupes d'utilisateurs.

  3. Si les permissions fines sont activées, vous pouvez également définir des règles par défaut pour les branches et tags.

Info

Ces paramètres par défaut s'appliquent uniquement aux nouveaux dépôts. Les dépôts existants ne sont pas modifiés.

Jenkins

L'onglet "Jenkins" permet d'ajouter des webhooks Jenkins qui seront déclenchés pour tous les dépôts du projet, évitant de configurer un webhook sur chaque dépôt individuellement.

Articles Liés