Aller au contenu principal

Jira Data Center

Jira Data Center (ainsi que l’ancien Jira Server) est la variante auto-hébergée de l’outil de suivi d’Atlassian, accessible sous votre propre nom d’hôte (par ex. https://jira.example.com/browse/<KEY>-<NUMBER>). Le modèle d’URL est le même que pour Jira Cloud ; seul le nom d’hôte change.

Côté Forgejo : suivi de tickets externe

Paramètres du dépôt → Fonctionnalités → Tickets → Utiliser un système de suivi d’issues externe.

ChampValeur
External issue tracker URLhttps://jira.example.com/browse/{user}-{index}
External issue tracker URL formathttps://jira.example.com/browse/{user}-{index}
External issue tracker number formatRegexp
External issue tracker number format regexp([A-Z][A-Z0-9]+)-([0-9]+)

Remplacez jira.example.com par le nom d’hôte de votre Data Center. Si votre Jira se trouve derrière un VPN ou sur un réseau privé, le lien fonctionne quand même : l’URL ne s’ouvre que dans le navigateur de l’utilisateur, jamais depuis le backend de fremforge.

Format de message de commit recommandé

fix(auth): session-token refresh race

PROJ-456

Même convention que pour Jira Cloud. Les références se placent à la fin du corps du commit.

Côté outil de suivi : DVCS Connector (facultatif)

La voie classique pour relier Jira DC et Git est le plugin DVCS Connector (gratuit, livré avec Jira depuis la version 8.x) :

  1. Jira DC → Settings → Applications → DVCS accounts → Link Bitbucket or GitHub account.
  2. Le DVCS Connector ne prend aujourd’hui en charge nativement que Bitbucket et GitHub ; pour Forgejo, passez par le webhook générique :
    • Jira → Settings → System → WebHooks → Create a WebHook.
    • URL : https://jira.example.com/rest/api/2/issue/{issue.key}/remotelink (ou le point de terminaison d’automatisation personnalisé de votre instance).
  3. Dans fremforge : Paramètres du dépôt → Webhooks → Ajouter un webhook → Forgejo → collez l’URL du webhook DC. Cochez Push et Pull Request.

Si votre Jira DC n’expose aucune surface publique, le webhook est la bonne primitive : fremforge envoie ses POST depuis son proxy sortant (le nom d’hôte de votre Jira étant autorisé en sortie via admin → Intégration → Webhooks).

Conséquences en matière de sous-traitance

Auto-hébergé = aucun nouveau sous-traitant ultérieur. Jira DC tourne dans votre infrastructure (sur site, dans votre AWS ou votre Azure). Les métadonnées de commit ne franchissent jamais votre périmètre :

  • Aucun avenant au DPA n’est nécessaire au-delà de ce que vous avez déjà pour votre propre déploiement de Jira DC.
  • La souveraineté reste intacte : fremforge et votre Jira DC restent tous deux dans l’UE (ou là où vous les avez déployés).

C’est la variante de Jira recommandée pour les clients attentifs à la souveraineté.

Ce que cette intégration ne fait pas

  • Pas de fermeture automatique à la fusion (Data Center prend en charge des règles d’automatisation via le plugin Automation for Jira ; configurez ces règles sur la charge utile du webhook entrant).
  • L’ancienne syntaxe « smart commits » (PROJ-123 #close) exige le DVCS Connector et un collecteur de commits côté Bitbucket/GitHub ; avec Forgejo, l’équivalent est une règle d’automatisation de votre côté qui lit la charge utile du webhook.
  • Calendrier de migration : si vous quittez Jira DC ET passez à fremforge dans la même période, faites une dernière liaison au moment de la bascule puis figez ; faire tourner les deux webhooks en parallèle pendant une longue migration produit des entrées « linked commit » en double.
Jira CloudAzure Boards