doc-locale/fr-fr/administration/settings/jira_cloud_app.md
{{< details >}}
{{< /details >}}
[!note] Cette page contient la documentation administrateur de l'application GitLab pour Jira Cloud. Pour la documentation utilisateur, voir Application GitLab pour Jira Cloud.
Avec l'application GitLab pour Jira Cloud, vous pouvez connecter GitLab et Jira Cloud pour synchroniser les informations de développement en temps réel. Vous pouvez consulter ces informations dans le panneau de développement Jira.
Pour configurer l'application GitLab pour Jira Cloud sur votre instance GitLab Self-Managed, effectuez l'une des opérations suivantes :
<i class="fa-youtube-play" aria-hidden="true"></i> Pour une vue d'ensemble, voir :
Les vidéos ci-dessus présentent l'ancienne interface Universal Plugin Manager, qui peut ne pas être disponible sur les instances Jira Cloud plus récentes. Les instructions suivantes couvrent les interfaces de gestion des applications anciennes et nouvelles.
Si vous installez l'application GitLab pour Jira Cloud depuis l'Atlassian Marketplace, vous pouvez utiliser la chaîne d'outils de projet développée et maintenue par Atlassian pour lier des dépôts GitLab à des projets Jira. La chaîne d'outils de projet n'affecte pas la façon dont les informations de développement sont synchronisées entre GitLab et Jira Cloud.
Pour Jira Data Center ou Jira Server, utilisez le connecteur Jira DVCS développé et maintenu par Atlassian.
Que vous souhaitiez installer l'application GitLab pour Jira Cloud depuis l'Atlassian Marketplace ou manuellement, vous devez créer une application OAuth.
Prérequis :
Pour créer une application OAuth sur votre instance GitLab Self-Managed :
Dans le coin supérieur droit, sélectionnez Admin.
Dans la barre latérale gauche, sélectionnez Applications.
Sélectionnez New application.
Dans Redirect URI :
https://gitlab.com/-/jira_connect/oauth_callbacks.<instance_url>/-/jira_connect/oauth_callbacks et remplacez <instance_url> par l'URL de votre instance.Décochez les cases Fiables et Confidentiel.
[!note] Vous devez décocher ces cases pour éviter les erreurs de connexion.
Dans Périmètre d'accès, cochez uniquement la case api.
Sélectionnez Enregistrer l'application.
Copiez la valeur de Identifiant de l'application.
Dans la barre latérale gauche, sélectionnez Paramètres > Général.
Développez Application GitLab pour Jira.
Collez la valeur de Identifiant de l'application dans ID de l'application Jira Connect.
Sélectionnez Sauvegarder les modifications.
{{< history >}}
org-admins introduite dans GitLab 16.6.{{< /history >}}
Dans votre organisation Atlassian, vous devez vous assurer que l'utilisateur Jira utilisé pour configurer l'application GitLab pour Jira Cloud est membre de l'un ou l'autre des groupes suivants :
org-admins). Les nouvelles organisations Atlassian utilisent la gestion centralisée des utilisateurs, qui contient le groupe org-admins. Les organisations Atlassian existantes sont en cours de migration vers la gestion centralisée des utilisateurs. Si disponible, vous devriez utiliser le groupe org-admins pour indiquer quels utilisateurs Jira peuvent gérer l'application GitLab pour Jira Cloud. Vous pouvez également utiliser le groupe site-admins.site-admins). Le groupe site-admins était utilisé avec la gestion des utilisateurs d'origine.Si nécessaire :
Browse users and groups à l'utilisateur Jira.{{< history >}}
{{< /history >}}
Vous pouvez utiliser l'application officielle GitLab pour Jira Cloud de l'Atlassian Marketplace avec votre instance GitLab Self-Managed.
Avec cette méthode :
Vous pouvez également installer l'application GitLab pour Jira Cloud manuellement si :
Pour configurer votre instance GitLab Self-Managed pour l'installation depuis l'Atlassian Marketplace dans GitLab 15.7 et versions ultérieures :
https://gitlab.com pour installer l'application depuis l'Atlassian Marketplace.Pour lier votre instance GitLab Self-Managed à l'application GitLab pour Jira Cloud :
Vous pouvez utiliser la console Rails pour vérifier si Jira Cloud est lié à :
Un groupe spécifique :
JiraConnectSubscription.where(namespace: Namespace.by_path('group/subgroup'))
Un projet spécifique :
Project.find_by_full_path('path/to/project').jira_subscription_exists?
N'importe quel groupe :
installation = JiraConnectInstallation.find_by_base_url("https://customer_name.atlassian.net")
installation.subscriptions
{{< history >}}
{{< /history >}}
[!warning] La précédente méthode d'installation manuelle reposait sur le mode de développement Atlassian Connect. Atlassian a désactivé les installations privées basées sur Connect le 31/03/2026. Si vous avez précédemment installé l'application manuellement avec le workflow App descriptor URL, migrez vers l'installation basée sur Forge décrite dans cette section.
Installez l'application GitLab pour Jira Cloud manuellement si vous ne pouvez pas utiliser l'annonce officielle de l'Atlassian Marketplace. Par exemple, si :
La méthode d'installation manuelle est désormais basée sur Atlassian Forge. Vous publiez une copie privée de l'application GitLab pour Jira Cloud Forge sous votre propre compte développeur Atlassian, pointant vers votre instance GitLab Self-Managed ou GitLab Dedicated.
<instance_url>/-/jira_connect (adresses IP Atlassian).*.atlassian.net pour envoyer les données de développement à Jira.*.atlassian.net est requis pour le panneau de développement et les autres surfaces côté Jira.envsubst, git et curl.Pour configurer votre instance GitLab Self-Managed pour l'installation manuelle :
Pour publier une copie privée de l'application GitLab pour Jira Cloud Forge et l'installer sur votre site Jira :
Clonez le dépôt gitlab-jira-forge :
git clone --depth 1 https://gitlab.com/gitlab-org/gitlab-jira-forge.git
cd gitlab-jira-forge
Exportez les variables d'environnement requises. Remplacez les valeurs d'exemple par l'URL de votre instance GitLab, le site Jira et vos identifiants Atlassian :
export GITLAB_URL=https://gitlab.example.com
export JIRA_SITE=acme.atlassian.net
export [email protected]
export FORGE_API_TOKEN=<your-atlassian-api-token>
Exécutez le script wrapper pour enregistrer, déployer et installer l'application :
./scripts/install-self-managed.sh
Le wrapper :
forge register lors de la première utilisation pour créer une application Forge sous votre compte Atlassian.manifest.yml à partir du modèle, associé à votre GITLAB_URL.forge deploy -e production.forge install --site $JIRA_SITE --product jira.Le script met en cache l'APP_ID enregistré dans .env.self-managed. Sauvegardez ce fichier : si vous le perdez, vous devrez réenregistrer l'application, ce qui force tous les sites Jira installés à réinstaller.
Pour des instructions pas à pas, les commandes forge manuelles, le dépannage et le workflow de mise à niveau, consultez le guide d'installation Self-Managed dans le dépôt gitlab-jira-forge.
Une fois l'application installée, configurez l'application GitLab pour Jira Cloud dans Jira pour lier vos espaces de nommage GitLab.
Pour intégrer les modifications de manifeste en amont dans votre application Forge privée, réexécutez le wrapper avec --update :
./scripts/install-self-managed.sh --update
Le script avance rapidement le clone local, régénère le manifeste et redéploie l'application. Pour plus d'informations sur les mises à niveau de versions mineures et majeures, voir Mise à niveau dans le guide d'installation Self-Managed.
Utilisez l'application GitLab pour Jira pour connecter plusieurs instances GitLab à une seule instance Jira Cloud. Les méthodes d'installation dépendent des instances que vous souhaitez connecter.
Prérequis :
Pour GitLab.com + GitLab Self-Managed :
Pour plusieurs instances GitLab Self-Managed :
Jira Cloud affiche une application GitLab pour Jira Cloud pour chaque installation.
Une seule instance GitLab par organisation peut utiliser l'annonce officielle de l'Atlassian Marketplace.
[!note] Pour la plupart des utilisateurs, cette configuration n'est pas nécessaire. Pour connecter Jira Cloud à plusieurs instances, vous pouvez connecter chaque instance avec l'application GitLab pour Jira Cloud.
Une instance GitLab peut servir de proxy pour d'autres instances GitLab via l'application GitLab pour Jira Cloud. Vous pouvez vouloir utiliser un proxy si vous gérez plusieurs instances GitLab mais souhaitez installer manuellement l'application une seule fois.
Pour configurer votre instance GitLab pour servir de proxy :
Les autres instances GitLab qui utilisent le proxy doivent configurer les paramètres suivants pour pointer vers l'instance proxy :
Les considérations de sécurité suivantes sont spécifiques à l'administration de l'application. Pour les considérations relatives à l'utilisation de l'application, voir considérations de sécurité.
Lorsque vous installez l'application GitLab pour Jira Cloud depuis l'Atlassian Marketplace , GitLab.com reçoit des événements du cycle de vie de Jira. Ces événements se limitent à l'installation ou à la désinstallation de l'application dans votre projet Jira.
Lors de l'événement d'installation, GitLab.com reçoit un secret token de Jira. GitLab.com stocke ce jeton chiffré avec AES256-GCM pour vérifier ultérieurement les événements du cycle de vie entrants provenant de Jira.
GitLab.com transfère ensuite le jeton à votre instance GitLab Self-Managed afin que votre instance puisse authentifier ses requêtes vers Jira avec le même jeton. Votre instance GitLab Self-Managed est également notifiée de l'installation ou de la désinstallation de l'application GitLab pour Jira Cloud.
Lorsque des données sont envoyées depuis votre instance GitLab Self-Managed vers le panneau de développement Jira, elles sont envoyées directement de votre instance GitLab Self-Managed vers Jira et non vers GitLab.com. GitLab.com n'utilise pas le jeton pour accéder aux données de votre projet Jira. Votre instance GitLab Self-Managed utilise le jeton pour accéder aux données.
Pour plus d'informations sur les événements du cycle de vie et les charges utiles que GitLab.com reçoit, consultez la documentation Atlassian.
sequenceDiagram
accTitle: Dataflow of the GitLab for Jira Cloud app installed from the Atlassian Marketplace
accDescr: How GitLab.com handles lifecycle events when the GitLab for Jira Cloud app was installed from the Atlassian Marketplace
participant Jira
participant Your instance
participant GitLab.com
Jira->>+GitLab.com: App install/uninstall event
GitLab.com->>-Your instance: App install/uninstall event
Your instance->>Jira: Your development data
Lorsque vous avez installé l'application GitLab pour Jira Cloud depuis l'Atlassian Marketplace, les liens pour créer une branche depuis le panneau de développement dirigent initialement l'utilisateur vers GitLab.com.
Jira envoie un jeton JWT à GitLab.com. GitLab.com traite la requête en vérifiant le jeton, puis redirige la requête vers votre instance GitLab.
GitLab ne partage pas de jeton d'accès avec Jira. Cependant, les utilisateurs doivent s'authentifier via OAuth pour configurer l'application.
Un jeton d'accès est récupéré via un flux OAuth PKCE et stocké uniquement côté client. Le frontend de l'application qui initialise le flux OAuth est une application JavaScript chargée depuis GitLab via un iframe sur Jira.
L'application OAuth doit avoir la portée api, qui accorde un accès complet en lecture et en écriture à l'API. Cet accès inclut tous les groupes et projets, le registre de conteneurs et le registre de paquets. Cependant, l'application GitLab pour Jira Cloud n'utilise cet accès que pour :
L'accès via OAuth n'est nécessaire que pendant la durée où un utilisateur configure l'application GitLab pour Jira Cloud. Pour plus d'informations, voir Expiration du jeton d'accès.
Vous devriez éviter d'utiliser un proxy inverse devant votre instance GitLab Self-Managed si possible. Envisagez plutôt d'utiliser une adresse IP publique et de sécuriser le domaine avec un pare-feu.
Si vous devez utiliser un proxy inverse pour l'application GitLab pour Jira Cloud sur une instance GitLab Self-Managed qui n'est pas accessible directement depuis Internet, gardez à l'esprit les points suivants :
gitlab-jira-connect-${host}. Sinon, vous pourriez obtenir une erreur Failed to link group.Ce bloc de serveur est un exemple de la façon de configurer un proxy inverse pour GitLab qui fonctionne avec Jira Cloud :
server {
listen *:80;
server_name gitlab.mycompany.com;
server_tokens off;
location /.well-known/acme-challenge/ {
root /var/www/;
}
location / {
return 301 https://gitlab.mycompany.com:443$request_uri;
}
}
server {
listen *:443 ssl;
server_tokens off;
server_name gitlab.mycompany.com;
ssl_certificate /etc/letsencrypt/live/gitlab.mycompany.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/gitlab.mycompany.com/privkey.pem;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384';
ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_session_timeout 1d;
access_log "/var/log/nginx/proxy_access.log";
error_log "/var/log/nginx/proxy_error.log";
location / {
proxy_pass https://gitlab.internal;
proxy_hide_header upgrade;
proxy_set_header Host gitlab.mycompany.com:443;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
}
Dans cet exemple :
gitlab.mycompany.com par le FQDN du proxy inverse et gitlab.internal par le FQDN GitLab interne.ssl_certificate et ssl_certificate_key sur un certificat valide (l'exemple utilise Certbot).Host sur le FQDN du proxy inverse pour s'assurer que GitLab et Jira Cloud peuvent se connecter correctement.Vous devez utiliser le FQDN du proxy inverse uniquement pour connecter Jira Cloud à GitLab. Vous devez continuer à accéder à GitLab depuis le FQDN GitLab interne. Si vous accédez à GitLab depuis le FQDN du proxy inverse, GitLab peut ne pas fonctionner comme prévu. Pour plus d'informations, voir le ticket 21319.
{{< history >}}
{{< /history >}}
Lorsque GitLab reçoit un jeton JWT de Jira, GitLab vérifie le jeton en contrôlant l'audience JWT. Par défaut, l'audience est dérivée de votre FQDN GitLab interne.
Dans certaines configurations de proxy inverse, vous devrez peut-être définir le FQDN du proxy inverse comme audience JWT supplémentaire. Pour définir une audience JWT supplémentaire :
https://gitlab.mycompany.com).