Connexion d'un référentiel Azure DevOps

Orbit déploie à partir d'Azure Repos, l'hébergement git au sein d'Azure DevOps. Connectez-vous une fois, choisissez un référentiel, et chaque envoi crée et met en direct. Ce guide couvre les deux façons de se connecter, la sélection d'un référentiel, et les deux points où Azure diffère des autres fournisseurs.

Deux façons de se connecter et pourquoi il y en a deux

Les organisations Azure DevOps peuvent bloquer les applications tierces au niveau du locataire, et beaucoup le font. Si la vôtre le fait, le bouton de connexion ne fonctionnera pour vous quoi qu'il en soit, donc Orbit propose une deuxième porte qui fonctionne toujours.

• Connectez-vous avec Microsoft. Un clic, rien à copier-coller. Disponible quand votre organisation autorise les applications tierces.
• Jeton d'accès personnel. Fonctionne pour chaque organisation, y compris celles qui bloquent les applications. Vous collez un nom d'organisation et un jeton que vous créez dans Azure DevOps.

Les deux portes mènent exactement aux mêmes fonctionnalités. Aucune n'est une version réduite de l'autre.

Avant de commencer

Option A : se connecter avec Microsoft

1. Dans KPanel, cliquez sur Orbit dans la barre latérale de gauche.
2. Cliquez sur Nouveau projet.
3. Laissez le mode défini sur Importer un référentiel Git.
4. Choisissez l'onglet Azure DevOps, puis cliquez sur Connecter Azure DevOps.

Vous êtes envoyé à Microsoft pour vous connecter et approuver l'accès. Approuvez-le et vous êtes renvoyé à KPanel avec vos référentiel chargés.

Si votre organisation bloque l'application, Microsoft refuse et KPanel affiche la raison qu'il a donnée. Ce n'est pas quelque chose que vous pouvez réessayer à votre façon: utilisez le jeton d'accès personnel ci-dessous, ou demandez à un administrateur de permettre l'application.

Option B : Jeton d'accès personnel

Créez d'abord le jeton dans Azure DevOps.

1. Dans Azure DevOps, ouvrez Paramètres utilisateur, puis Jetons d'accès personnel, puis Nouveau jeton.
2. Choisissez l'organisation à partir de laquelle vous souhaitez déployer.
3. Accordez ces trois portées et rien de plus que ces trois :
   • Code (Lecture) pour qu'Orbit puisse lister vos référentiels et télécharger le commit qu'il construit.
   • Code (Statut) pour que le résultat de la construction apparaisse sur le commit et sur la demande d'extraction.
   • Crochets de service (Lecture et écriture) pour qu'Orbit puisse s'abonner à vos envois.
4. Copiez le jeton. Azure ne l'affiche qu'une fois.

Ensuite dans KPanel :

1. Ouvrez Orbit, puis Nouveau projet, puis l'onglet Azure DevOps.
2. Sous Connecter avec un jeton d'accès personnel, entrez le nom de votre organisation. C'est la partie de l'adresse de votre référentiel immédiatement après dev.azure.com, donc pour https://dev.azure.com/contoso/web-platform/_git/storefront l'organisation est contoso.
3. Collez le jeton et cliquez sur Connecter Azure DevOps.

Orbit utilise immédiatement le jeton pour lister vos référentiels. S'il est refusé, on vous dit quelles portées manquent plutôt que de vous être demandé de vérifier votre jeton, car un jeton qui liste les référentiels mais ne peut pas créer un crochet de service a exactement la forme qui se connecte proprement puis ne déploie jamais rien.

Votre jeton est chiffré avant d'être stocké et n'est jamais utilisé que contre l'organisation que vous avez nommée.

Sélectionner un référentiel

Vos référentiels apparaissent sous forme de liste, nommée organisation / project / repository. Les référentiels Azure contiennent trois parties, pas deux, car deux projets dans une organisation peuvent chacun contenir un référentiel portant le même nom.

Cliquez sur Sélectionner à côté de celui que vous voulez, puis terminez le projet comme d'habitude : nom, framework, paramètres de construction, variables d'environnement.

Si un référentiel manque

• Vérifiez l'organisation. Un jeton d'accès personnel appartient à UNE organisation, donc un référentiel dans une autre ne s'affichera pas. Connectez également cette organisation.
• Vérifiez votre accès au référentiel lui-même dans Azure DevOps.
• Vérifiez si le référentiel est désactivé dans Azure. Orbit ne liste pas les référentiels désactivés, car ils ne peuvent pas être construits.

Deux points où Azure diffère

Ce sont des différences réelles, pas des lacunes que nous n'avons pas atteintes, et les deux sont énoncées ici plutôt que découvertes plus tard.

Le répertoire racine du monorepo ne saute pas les envois

Sur les autres fournisseurs, Orbit lit la liste des fichiers que chaque envoi a modifiée, et un projet monorepo peut sauter une construction quand rien sous son répertoire racine n'a bougé. Azure n'envoie pas cette liste. Orbit construit donc à chaque envoi plutôt que de deviner, car deviner l'autre façon ignorerait silencieusement les déploiements que vous attendiez.

Votre paramètre répertoire racine décide toujours où la construction s'exécute. Cela ne filtre pas simplement en plus quels envois construisent.

Les demandes d'extraction à partir de fourches ne sont pas construites

Orbit construit un aperçu de demande d'extraction avec les variables d'environnement d'aperçu de votre projet. C'est sûr pour une demande d'extraction de votre propre référentiel et ce n'est pas sûr pour une d'une fourche, qui est une proposition de quelqu'un sans relation avec votre compte.

Sur GitHub, Orbit peut proposer un aperçu de fourche car GitHub publie le commit proposé dans votre propre référentiel, donc nous n'avons jamais à nous authentifier par rapport à la copie du contributeur. Azure ne publie pas d'équivalent, donc Orbit refuse les demandes d'extraction de fourches et le dit sur le commit plutôt que de laisser un aperçu qui ne s'affiche jamais.

Les demandes d'extraction à partir de branches au sein de votre propre référentiel se construisent normalement.

Ensuite

Poussez vers votre branche de production et Orbit construit et déploie. Le résultat de la construction est affiché sur le commit dans Azure DevOps, donc il s'affiche sur le commit et sur toute demande d'extraction à laquelle le commit appartient, et vos stratégies de branche peuvent l'exiger.

Voir aussi

• Qu'est-ce qu'Orbit ?
• Déploiement avec Orbit
• Connexion d'un référentiel GitHub