Générer des référentiels GitHub

Azure DevOps Services

Azure Pipelines peut automatiquement générer et valider chaque demande de tirage, et les commiter dans votre dépôt GitHub. Cet article explique comment configurer l’intégration entre GitHub et Azure Pipelines.

Si vous débutez avec l’intégration des pipelines à GitHub, suivez les étapes décrites dans Créer votre premier pipeline. Revenez à cet article pour en savoir plus sur la configuration et la personnalisation de l’intégration entre GitHub et Azure Pipelines.

Organisations et utilisateurs

GitHub et Azure Pipelines sont deux services indépendants qui s’intègrent bien ensemble. Chacun d’entre eux a sa propre organisation et sa propre gestion des utilisateurs. Cette section propose une suggestion sur la façon de répliquer l’organisation et les utilisateurs de GitHub vers Azure Pipelines.

Organisations

La structure de GitHub se compose de comptes d’utilisateur et d’organisations qui contiennent des référentiels. Consultez la documentation de GitHub.

La structure d’Azure DevOps est constituée d’organisations contenant des projets. Consultez Planifier votre structure organisationnelle.

Azure DevOps peut refléter votre structure GitHub avec :

• Une organisation DevOps pour votre organisation GitHub ou votre compte d’utilisateur
• DevOps Projects pour vos référentiels GitHub

Pour configurer une structure identique dans Azure DevOps :

1. Créez une organisation DevOps nommée d’après votre organisation GitHub ou votre compte d’utilisateur. Elle aura une URL comme https://dev.azure.com/your-organization.
2. Dans l’organisation DevOps, créez des projets nommés d’après vos référentiels. Ils auront des URL comme https://dev.azure.com/your-organization/your-repository.
3. Dans le projet DevOps, créez des pipelines nommés d’après l’organisation GitHub et le référentiel qu’ils créent, tels que your-organization.your-repository. Il est ensuite clair pour quels référentiels ils sont.

En suivant ce modèle, vos référentiels GitHub et Azure DevOps Projects auront des chemins d’URL correspondants. Par exemple :

Utilisateurs

Vos utilisateurs GitHub n’ont pas automatiquement accès à Azure Pipelines. Azure Pipelines ignore les identités GitHub. Pour cette raison, il n’existe aucun moyen de configurer Azure Pipelines pour avertir automatiquement les utilisateurs d’une défaillance de build ou d’une défaillance de validation de demande de tirage à l’aide de leur identité GitHub et de leur adresse e-mail. Vous devez créer explicitement de nouveaux utilisateurs dans Azure Pipelines pour répliquer des utilisateurs GitHub. Une fois que vous avez créé de nouveaux utilisateurs, vous pouvez configurer leurs autorisations dans Azure DevOps pour refléter leurs autorisations dans GitHub. Vous pouvez également configurer des notifications dans DevOps à l’aide de leur identité DevOps.

Rôles de l’organisation GitHub

Les rôles membres de l’organisation GitHub se trouvent à l’adresse https://github.com/orgs/your-organization/people (remplacer your-organization).

Les autorisations des membres de l’organisation DevOps se trouvent à l’adresse https://dev.azure.com/your-organization/_settings/security (remplacer your-organization).

Les rôles d’une organisation GitHub et les rôles équivalents dans une organisation Azure DevOps sont indiqués ci-dessous.

Rôles de compte d’utilisateur GitHub

Un compte d’utilisateur GitHub a un rôle, qui est la propriété du compte.

Les autorisations des membres de l’organisation DevOps se trouvent à l’adresse https://dev.azure.com/your-organization/_settings/security (remplacer your-organization).

Le rôle de compte d’utilisateur GitHub est mappé aux autorisations de l’organisation DevOps comme suit.

Autorisations de référentiel GitHub

Les autorisations de référentiel GitHub se trouvent à l’adresse https://github.com/your-organization/your-repository/settings/collaboration (remplacer your-organization et your-repository).

Les autorisations du projet DevOps se trouvent à l’adresse https://dev.azure.com/your-organization/your-project/_settings/security (remplacer your-organization et your-project).

Les autorisations équivalentes entre les référentiels GitHub et Azure DevOps Projects sont les suivantes.

Si votre référentiel GitHub accorde l’autorisation aux équipes, vous pouvez créer des équipes correspondantes dans la section Teams de vos paramètres de projet Azure DevOps. Ajoutez ensuite les équipes aux groupes de sécurité ci-dessus, tout comme les utilisateurs.

Autorisations spécifiques au pipeline

Pour accorder des autorisations aux utilisateurs ou aux équipes pour des pipelines spécifiques dans un projet DevOps, procédez comme suit :

1. Visitez la page Pipelines du projet (par exemple, https://dev.azure.com/your-organization/your-project/_build).
2. Sélectionnez le pipeline pour lequel définir des autorisations spécifiques.
3. Dans le menu contextuel '...', sélectionnez Sécurité.
4. Sélectionnez Ajouter... pour ajouter un utilisateur, une équipe ou un groupe spécifique et personnaliser ses autorisations pour le pipeline.

Accès aux référentiels GitHub

Azure Pipelines doit avoir accès à vos référentiels pour déclencher leurs générations et extraire leur code pendant les générations.

Il y a trois types d’authentification pour accorder à Azure Pipelines l’accès à vos dépôts GitHub pendant la création d’un pipeline.

Authentification d’application GitHub

L’application GitHub Azure Pipelines est le type d’authentification recommandé pour les pipelines d’intégration continue. Après avoir installé l’application GitHub dans votre compte ou votre organisation GitHub, votre pipeline s’exécute sans utiliser votre identité GitHub personnelle. Les builds et les mises à jour d’état GitHub sont effectués à l’aide de l’identité Azure Pipelines. L’application fonctionne avec GitHub Checks pour afficher les résultats de build, de test et de couverture du code dans GitHub.

Pour utiliser l’application GitHub, installez-la dans votre organisation ou compte d’utilisateur GitHub pour certains référentiels ou tous les référentiels. L’application GitHub peut être installée et désinstallée à partir de la page d’accueil de l’application.

Après l’installation, l’application GitHub devient la méthode d’authentification d’Azure Pipelines par défaut sur GitHub (au lieu d’OAuth) lorsque les pipelines sont créés pour les référentiels.

Si vous installez l’application GitHub pour tous les référentiels d’une organisation GitHub, vous n’avez pas besoin de vous soucier du fait qu’Azure Pipelines envoie des e-mails de masse ou configure automatiquement des pipelines en votre nom. En guise d’alternative à l’installation de l’application pour tous les référentiels, les administrateurs de référentiels peuvent l’installer une à la fois pour les référentiels individuels. Cela nécessite davantage de travail pour les administrateurs, mais n’a aucun avantage ni inconvénient.

Autorisations nécessaires dans GitHub

L’installation de l’application GitHub Azure Pipelines nécessite que vous soyez propriétaire d’organisation GitHub ou administrateur de référentiel GitHub. En outre, pour créer un pipeline pour un référentiel GitHub avec des déclencheurs d’intégration continue et de demande de tirage, vous devez disposer des autorisations GitHub requises configurées. Sinon, le référentiel n’apparaît pas dans la liste des référentiels lors de la création d’un pipeline. Selon le type d’authentification et la propriété du référentiel, vérifiez que l’accès approprié est configuré.

• Si le référentiel se trouve dans votre compte GitHub personnel, installez l’application GitHub Azure Pipelines dans votre compte GitHub personnel, et vous serez en mesure de répertorier ce référentiel lors de la création du pipeline dans Azure Pipelines.

• Si le référentiel se trouve dans le compte GitHub personnel d’une autre personne, cette dernière doit installer l’application GitHub Azure Pipelines dans son compte GitHub personnel. Vous devez être ajouté en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail. Une fois cela fait, vous pouvez créer un pipeline pour ce référentiel.

• Si le référentiel se trouve dans une organisation GitHub que vous possédez, installez l’application GitHub Azure Pipelines dans l’organisation GitHub. Vous ou votre équipe devez également être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ».

• Si le référentiel se trouve dans une organisation GitHub appartenant à une autre personne, un propriétaire de l’organisation GitHub ou un administrateur de référentiel doit installer l’application GitHub Azure Pipelines dans l’organisation. Vous ou votre équipe devez être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail.

Autorisations des applications GitHub

L’application GitHub demande les autorisations suivantes pendant l’installation :

Résolution des problèmes d’installation de l’application GitHub

GitHub peut afficher une erreur telle que :

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

Cela signifie que l’application GitHub est probablement déjà installée pour votre organisation. Lorsque vous créez un pipeline pour un référentiel dans l’organisation, l’application GitHub est automatiquement utilisée pour la connexion à GitHub.

Créer des pipelines dans plusieurs organisations et projets Azure DevOps

Une fois l’application GitHub installée, les pipelines peuvent être créés pour les référentiels de l’organisation dans différents projets et organisations Azure DevOps. Toutefois, si vous créez des pipelines pour un référentiel unique dans plusieurs organisations Azure DevOps, seuls les pipelines de la première organisation peuvent être déclenchés automatiquement par des validations GitHub ou des demandes de tirage. Les builds manuels ou planifiés sont toujours possibles dans les organisations Azure DevOps secondaires.

Authentification OAuth

OAuth est le type d’authentification le plus simple à utiliser pour les dépôts dans votre compte GitHub personnel. Les mises à jour d’état GitHub sont effectuées pour le compte de votre identité GitHub personnelle. Pour que les pipelines continuent de fonctionner, l’accès à votre référentiel doit rester actif. Certaines fonctionnalités GitHub, telles que les vérifications, ne sont pas disponibles avec OAuth et nécessitent l’application GitHub.

Pour utiliser OAuth, sélectionnez Choisir une autre connexion sous la liste des référentiels lors de la création d’un pipeline. Sélectionnez ensuite Autoriser pour vous connecter à GitHub et autoriser avec OAuth. Une connexion OAuth sera enregistrée dans votre projet Azure DevOps pour une utilisation ultérieure, ainsi que dans le pipeline en cours de création.

Autorisations nécessaires dans GitHub

Pour créer un pipeline pour un référentiel GitHub avec des déclencheurs d’intégration continue et de demande de tirage, vous devez disposer des autorisations GitHub requises configurées. Sinon, le référentiel n’apparaît pas dans la liste des référentiels lors de la création d’un pipeline. Selon le type d’authentification et la propriété du référentiel, vérifiez que l’accès approprié est configuré.

• Si le référentiel se trouve dans votre compte GitHub personnel, au moins une fois, authentifiez-vous auprès de GitHub avec OAuth à l’aide de vos informations d’identification de compte GitHub personnelles. Cela peut être effectué dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Authorize. Accordez à Azure Pipelines l’accès à vos référentiels sous « Autorisations » ici.

• Si le référentiel se trouve dans le compte GitHub personnel d’une autre personne, au moins une fois, l’autre personne doit s’authentifier auprès de GitHub avec OAuth à l’aide de ses informations d’identification de compte GitHub personnelles. Cela peut être effectué dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Authorize. L’autre personne doit accorder à Azure Pipelines l’accès à ses référentiels sous « Autorisations » ici. Vous devez être ajouté en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail.

• Si le référentiel se trouve dans une organisation GitHub que vous possédez, au moins une fois, authentifiez-vous auprès de GitHub avec OAuth à l’aide de vos informations d’identification de compte GitHub personnelles. Cela peut être effectué dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Authorize. Accordez à Azure Pipelines l’accès à votre organisation sous « Accès à l’organisation » ici. Vous ou votre équipe devez être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ».

• Si le référentiel se trouve dans l’organisation GitHub appartenant à une autre personne, au moins une fois, un propriétaire de l’organisation GitHub doit s’authentifier auprès de GitHub avec OAuth à l’aide de ses informations d’identification de compte GitHub personnelles. Cela peut être effectué dans les paramètres du projet Azure DevOps sous Pipelines > Connexions de service > Nouvelle connexion de service > GitHub > Authorize. Le propriétaire de l’organisation doit accorder à Azure Pipelines l’accès à l’organisation sous « Accès à l’organisation » ici. Vous ou votre équipe devez être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail.

Révoquer l’accès OAuth

Après avoir autorisé Azure Pipelines à utiliser OAuth, pour le révoquer ultérieurement et empêcher une autre utilisation, consultez Applications OAuth dans vos paramètres GitHub. Vous pouvez également le supprimer de la liste des connexions de service GitHub dans vos paramètres de projet Azure DevOps.

Authentification par jeton d’accès personnel (PAT)

Les PAT sont effectivement identiques à OAuth, mais vous permettent de contrôler quelles autorisations sont accordées à Azure Pipelines. Les builds et les mises à jour d’état GitHub sont effectués au nom de votre identité GitHub personnelle. Pour que les builds continuent de fonctionner, l’accès à votre référentiel doit rester actif.

Pour créer un PAT, visitez Jeton d’accès personnel dans vos paramètres GitHub. Les demande d’autorisations requises sont repo, admin:repo_hook, read:user et user:email. Il s’agit des mêmes autorisations requises lors de l’utilisation d’OAuth ci-dessus. Copiez le PAT généré dans le presse-papiers et collez-le dans une nouvelle connexion de service GitHub dans vos paramètres de projet Azure DevOps. Pour un rappel ultérieur, nommez la connexion de service d’après votre nom d’utilisateur GitHub. Elle sera disponible dans votre projet Azure DevOps pour une utilisation ultérieure lors de la création de pipelines.

Autorisations nécessaires dans GitHub

Pour créer un pipeline pour un référentiel GitHub avec des déclencheurs d’intégration continue et de demande de tirage, vous devez disposer des autorisations GitHub requises configurées. Sinon, le référentiel n’apparaît pas dans la liste des référentiels lors de la création d’un pipeline. Selon le type d’authentification et la propriété du référentiel, vérifiez que l’accès suivant est configuré.

• Si le référentiel se trouve dans votre compte GitHub personnel, le PAT doit avoir les étendues d’accès requises sous Jetons d’accès personnels : repo, admin:repo_hook, read:user et user:email.

• Si le référentiel se trouve dans le compte GitHub personnel d’une autre personne, le PAT doit avoir les étendues d’accès requises sous Jetons d’accès personnel : repo, admin:repo_hook, read:user et user:email. Vous devez être ajouté en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail.

• Si le référentiel se trouve dans une organisation GitHub que vous possédez, le PAT doit avoir les étendues d’accès requises sous Jetons d’accès personnels : repo, admin:repo_hook, read:user et user:email. Vous ou votre équipe devez être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ».

• Si le référentiel se trouve dans une organisation GitHub appartenant à une autre personne, le PAT doit avoir les étendues d’accès requises sous Jetons d’accès personnels : repo, admin:repo_hook, read:user et user:email. Vous ou votre équipe devez être ajoutés en tant que collaborateur dans les paramètres du référentiel sous « Collaborateurs et équipes ». Acceptez l’invitation à être un collaborateur à l’aide du lien qui vous est envoyé par e-mail.

Révoquer l’accès PAT

Après avoir autorisé Azure Pipelines à utiliser un PAT, pour le supprimer ultérieurement et empêcher une utilisation ultérieure, consultez Jetons d’accès personnels dans vos paramètres GitHub. Vous pouvez également le supprimer de la liste des connexions de service GitHub dans vos paramètres de projet Azure DevOps.

Déclencheurs CI

Les déclencheurs d’intégration continue (CI) entraînent l’exécution d’un pipeline chaque fois que vous envoyez une mise à jour aux branches spécifiées ou que vous envoyez des étiquettes spécifiées.

trigger:
- main
- releases/*

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

# A pipeline with no CI trigger
trigger: none

Ignorer l’intégration continue pour les validations individuelles

Vous pouvez également indiquer à Azure Pipelines d’ignorer l’exécution d’un pipeline qu’un envoi déclencherait normalement. Il suffit d’inclure [skip ci] dans le message ou la description de l’une des validations qui font partie d’un envoi, et Azure Pipelines ignorera l’exécution de CI pour cette envoi. Vous pouvez également utiliser une des variantes suivantes.

• [skip ci] ou [ci skip]
• skip-checks: true ou skip-checks:true
• [skip azurepipelines] ou [azurepipelines skip]
• [skip azpipelines] ou [azpipelines skip]
• [skip azp] ou [azp skip]
• ***NO_CI***

Utilisation du type de déclencheur dans les conditions

Il est courant d’exécuter différentes étapes ou phases et différents travaux dans votre pipeline en fonction du type de déclencheur qui a démarré l’exécution. Pour ce faire, utilisez la variable système Build.Reason. Par exemple, ajoutez la condition suivante à votre étape, tâche ou phase pour l’exclure des validations de demande de tirage.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Comportement des déclencheurs lors de la création de nouvelles branches

Il est courant de configurer plusieurs pipelines pour le même dépôt. Par exemple, vous pouvez avoir un pipeline pour générer les documents de votre application et un autre pour générer le code source. Vous pouvez configurer des déclencheurs CI avec des filtres de branche et des filtres de chemin appropriés dans chacun de ces pipelines. Par exemple, vous souhaiterez peut-être qu’un pipeline se déclenche lorsque vous envoyez une mise à jour au dossier docs, et un autre lorsque vous envoyez une mise à jour au code de votre application. Dans ce cas, vous devez comprendre comment les pipelines sont déclenchés lorsqu’une nouvelle branche est créée.

Voici le comportement lorsque vous envoyez une nouvelle branche (qui correspond aux filtres de branche) vers votre dépôt :

• Si votre pipeline a des filtres de chemin d’accès, il est déclenché uniquement si la nouvelle branche a des modifications apportées aux fichiers qui correspondent à ce filtre de chemin d’accès.
• Si votre pipeline n’a pas de filtres de chemin d’accès, il est déclenché même s’il n’y a aucune modification dans la nouvelle branche.

Caractères génériques

Lorsque vous spécifiez une branche, une étiquette ou un chemin d’accès, vous pouvez utiliser un nom exact ou un caractère générique. Les modèles de caractères génériques permettent à * de faire correspondre zéro ou plusieurs caractères, et à ? de faire correspondre un caractère unique.

• Si vous commencez votre modèle avec * dans un pipeline YAML, vous devez encapsuler le modèle entre guillemets, comme "*-releases".
• Pour les branches et les balises :
  • Un caractère générique peut apparaître n’importe où dans le modèle.
• Pour les chemins d’accès :
  • Dans Azure DevOps Server 2022 et versions ultérieures, y compris Azure DevOps Services, un caractère générique peut apparaître n’importe où dans un modèle de chemin, et vous pouvez utiliser * ou ?.
  • Dans Azure DevOps Server 2020 et versions antérieures, vous pouvez inclure * comme caractère final, mais cela ne fait rien de différent de la spécification du nom de répertoire par lui-même. Vous ne pouvez pas inclure * au milieu d’un filtre de chemin d’accès, et vous ne pouvez pas utiliser ?.

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Déclencheurs PR

Les déclencheurs de demande de tirage (PR) causent l’exécution chaque fois qu’une demande de tirage est ouverte avec l’une des branches cibles spécifiées ou quand des mises à jour sont faites sur ce type de demande de tirage.

pr:
- main
- releases/*

pr:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

# specific branch
pr:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

# specific path
pr:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

# no PR triggers
pr: none

Si vous disposez d’une demande de tirage ouverte et que vous envoyez des modifications à sa branche source, plusieurs pipelines peuvent s’exécuter :

• Les pipelines qui ont un déclencheur de demande de tirage sur la branche cible de la demande de tirage s’exécutent sur la validation de fusion (le code fusionné entre les branches source et cible de la demande de tirage), qu’il existe ou non des validations envoyées (push) dont les messages ou descriptions contiennent [skip ci] (ou l’une de ses variantes).
• Les pipelines déclenchés par les modifications apportées à la branche source de la demande de tirage, s’il n’y a pas de validations envoyées dont les messages ou descriptions contiennent [skip ci] (ou l’une de ses variantes). Si au moins une validation envoyée contient [skip ci], les pipelines ne s’exécutent pas.

Enfin, après avoir fusionné la demande de tirage, Azure Pipelines exécute les pipelines CI déclenchés par des envois vers la branche cible, si le message ou la description de la validation de fusion ne contient pas [skip ci] (ou l’une de ses variantes).

Branches protégées

Vous pouvez exécuter un build de validation avec chaque validation ou demande de tirage qui cible une branche, et même empêcher la fusion des demandes de tirage jusqu’à ce qu’un build de validation réussisse.

Pour configurer les builds de validation obligatoires pour un référentiel GitHub, vous devez être son propriétaire, un collaborateur avec le rôle d’administrateur ou un membre de l’organisation GitHub avec le rôle d’écriture.

1. Tout d’abord, créez un pipeline pour le référentiel et générez-le au moins une fois afin que son état soit publié sur GitHub, ce qui rend GitHub conscient du nom du pipeline.

2. Ensuite, suivez la documentation de GitHub pour configurer des branches protégées dans les paramètres du référentiel.

   Pour la vérification de l’état, sélectionnez le nom de votre pipeline dans la liste Vérifications d’état.

   

Contributions provenant de sources externes

Si votre référentiel GitHub est open source, vous pouvez rendre votre projet Azure DevOps public afin que tout le monde puisse afficher les résultats de build, les journaux et les résultats des tests de votre pipeline sans se connecter. Lorsque les utilisateurs en dehors de votre organisation dupliquent votre référentiel et envoient des demandes de tirage, ils peuvent afficher l’état des builds qui valident automatiquement ces demandes de tirage.

Vous devez garder à l’esprit les considérations suivantes lors de l’utilisation d’Azure Pipelines dans un projet public lors de l’acceptation des contributions provenant de sources externes.

• Restrictions de l’accès
• Valider les contributions des duplications
• Considérations importantes relatives à la sécurité

Restrictions d'accès

Tenez compte des restrictions d’accès suivantes lorsque vous exécutez des pipelines dans des projets publics Azure DevOps :

• Secrets : par défaut, les secrets associés à votre pipeline ne sont pas mis à la disposition des validations de demandes de tirage des duplications. Consultez Valider les contributions des duplications.
• Accès inter-projets : tous les pipelines d’un projet public Azure DevOps s’exécutent avec un jeton d’accès limité au projet. Les pipelines d’un projet public peuvent accéder à des ressources telles que des artefacts de build ou des résultats de test uniquement dans le projet et non dans d’autres projets de l’organisation Azure DevOps.
• Packages Azure Artifacts : si vos pipelines ont besoin d’accéder aux packages à partir d’Azure Artifacts, vous devez accorder explicitement l’autorisation au compte Project Build Service d’accéder aux flux de package.

Contributions de duplications

Lorsque vous créez un pipeline, il est automatiquement déclenché pour les demandes de tirage à partir de duplications de votre référentiel. Vous pouvez modifier ce comportement, en tenant bien compte de la façon dont il affecte la sécurité. Pour activer ou désactiver ce comportement :

1. Accédez à votre projet Azure DevOps. Sélectionnez Pipelines, recherchez votre pipeline, puis sélectionnez Modifier.
2. Sélectionnez l’onglet Déclencheurs. Après avoir activé le déclencheur de demande de tirage, activez ou désactivez les demandes de tirage de build à partir de duplications de ce référentiel.

Par défaut, avec des pipelines GitHub, les secrets associés à votre pipeline de build ne sont pas mis à la disposition des builds de demandes de tirage de duplications. Ces secrets sont activés par défaut avec les pipelines GitHub Enterprise Server. Les secrets comprennent :

• Un jeton de sécurité avec accès à votre référentiel GitHub.
• Ces éléments, si votre pipeline les utilise :
  • Informations d’identification de connexion de service
  • Fichiers de la bibliothèque de fichiers sécurisés
  • Variables de build marquées comme secret

Pour contourner cette précaution sur les pipelines GitHub, activez la case à cocher Rendre les secrets disponibles pour les builds de duplications. Tenez compte de l’effet de ce paramètre sur la sécurité.

Pour plus d’informations, consultez Protection du référentiel - Duplications.

Vous pouvez définir de manière centralisée la façon dont les pipelines créent des demandes de tirage à partir de référentiels GitHub forkés à l’aide du contrôle Limit building pull requests from forked GitHub repositories (Limiter les demandes de tirage de génération à partir de référentiels GitHub dupliqués). Il est disponible au niveau de l’organisation et du projet. Vous pouvez choisir de :

• Désactiver la génération de demandes de tirage à partir de référentiels dupliqués (forkés)
• Générer en toute sécurité des demandes de tirage à partir de référentiels dupliqués (forkés)
• Personnaliser les règles pour la génération de demandes de tirage à partir de référentiels dupliqués (forkés)

À compter de Sprint 229, pour améliorer la sécurité de vos pipelines, Azure Pipelines ne génère plus automatiquement des demandes de tirage à partir de référentiels GitHub dupliqués. Pour les nouveaux projets et organisations, la valeur par défaut du paramètre Limiter les demandes de tirage de génération à partir de référentiels GitHub dupliqués est Désactiver la génération de demandes de tirage à partir de référentiels dupliqués.

Lorsque vous choisissez l’option Securely build pull requests from forked repositories (Générer de manière sécurisée des demandes de tirage à partir de référentiels dupliqués), tous les pipelines, à l’échelle de l’organisation et du projet, ne peuvent pas mettre des secrets à la disposition des builds de demandes de tirage à partir de référentiels dupliqués (forkés), ne peuvent pas faire en sorte que ces builds disposent des mêmes autorisations que les builds normales et doivent être déclenchés par un commentaire de demande de tirage. Les projets peuvent toujours décider de ne pas autoriser les pipelines à générer de telles demandes de tirage.

Lorsque vous choisissez l’option Personnaliser, vous pouvez définir comment restreindre les paramètres de pipeline. Par exemple, vous pouvez vous assurer que tous les pipelines nécessitent un commentaire afin de générer une demande de tirage à partir d’un référentiel GitHub dupliqué (forké), lorsque la demande de tirage appartient à des membres qui ne font pas partie de l’équipe et à des non-contributeurs. Toutefois, vous pouvez choisir de les autoriser à mettre des secrets à la disposition de ces builds. Les projets peuvent décider de ne pas autoriser les pipelines à générer de telles demandes de tirage, ou de les générer de manière sécurisée, ou d’avoir des paramètres encore plus restrictifs que ce qui est spécifié au niveau de l’organisation.

Le contrôle est désactivé pour les organisations existantes. À compter de septembre 2023, Générer en toute sécurité des demandes de tirage à partir de référentiels dupliqués (fork) est activé par défaut pour les nouvelles organisations.

Considérations importantes relatives à la sécurité

Un utilisateur GitHub peut dupliquer votre référentiel, le modifier et créer une demande de tirage pour proposer des modifications à votre référentiel. Cette demande de tirage peut contenir du code malveillant à exécuter dans le cadre de votre build déclenché. Ce code peut causer des dommages de la manière suivante :

• Fuite de secrets à partir de votre pipeline. Pour atténuer ce risque, n’activez pas la case à cocher Rendre les secrets disponibles pour les builds de référentiels si votre référentiel est public ou que des utilisateurs non approuvés peuvent envoyer des demandes de tirage qui déclenchent automatiquement des builds. qui est désactivée par défaut.

• Compromettez l’exécution de l’agent par l’ordinateur pour voler du code ou des secrets à partir d’autres pipelines. Pour atténuer ce problème :

  • Utilisez un pool d’agents hébergés par Microsoft pour générer des demandes de tirage à partir de duplications. Les ordinateurs d’agents hébergés par Microsoft sont immédiatement supprimés une fois qu’ils ont terminé un build. Il n’y a donc aucun impact durable s’ils sont compromis.

  • Si vous devez utiliser un agent autohébergé, ne stockez pas de secrets et n’exécutez pas d’autres builds et versions qui utilisent des secrets sur le même agent, sauf si votre référentiel est privé et que vous faites confiance aux créateurs de demandes de tirage.

Déclencheurs de commentaires

Les collaborateurs du référentiel peuvent commenter une demande de tirage pour exécuter manuellement un pipeline. Voici quelques raisons courantes pour lesquelles vous souhaiterez peut-être procéder comme suit :

• Vous ne souhaiterez peut-être pas générer automatiquement des demandes de tirage d’utilisateurs inconnus jusqu’à ce que leurs modifications puissent être examinées. Vous souhaitez qu’un des membres de votre équipe examine d’abord son code, puis exécute le pipeline. Il s’agit d’une mesure de sécurité généralement utilisée lors de la génération de code fourni à partir de référentiels dupliqués.
• Vous pouvez exécuter une suite de tests facultative ou une build de validation supplémentaire.

Pour activer les déclencheurs de commentaire, vous devez suivre les deux étapes suivantes :

1. Activez les déclencheurs de demande de tirage pour votre pipeline et assurez-vous que vous n’avez pas exclu la branche cible.
2. Dans le portail web Azure Pipelines, modifiez votre pipeline et choisissez Plus d’actions, Déclencheurs. Ensuite, sous Validation de demande d’extraction, activez Exiger le commentaire d’un membre de l’équipe avant de générer une demande de tirage.
   • Choisissez Sur toutes les demandes de tirage pour exiger le commentaire d’un membre de l’équipe avant de générer une demande de tirage. Avec ce flux de travail, un membre de l’équipe examine la demande de tirage et déclenche le build avec un commentaire une fois que la demande de tirage est considérée comme sécurisée.
   • Choisissez Uniquement sur les demandes de tirage de membres n’appartenant pas à l’équipe pour exiger le commentaire d’un membre de l’équipe uniquement lorsqu’une demande de tirage est effectuée par un membre n’appartenant pas à l’équipe. Dans ce flux de travail, un membre de l’équipe n’a pas besoin d’une révision de membre d’équipe secondaire pour déclencher un build.

Avec ces deux modifications, le build de validation de demande de tirage ne sera pas déclenché automatiquement, sauf si Uniquement sur les demandes de tirage de membres n’appartenant pas à l’équipe est sélectionné et que la demande de tirage est effectuée par un membre de l’équipe. Seuls les propriétaires et collaborateurs du référentiel disposant de l’autorisation 'Écriture' peuvent déclencher le build en commentant la demande de tirage avec /AzurePipelines run ou /AzurePipelines run <pipeline-name>.

Les commandes suivantes peuvent être émises à Azure Pipelines dans les commentaires :

Résoudre les problèmes liés aux déclencheurs de commentaires de demande de tirage

Si vous disposez des autorisations de référentiel nécessaires, mais que les pipelines ne sont pas déclenchés par vos commentaires, assurez-vous que votre appartenance est publique dans l’organisation du référentiel ou ajoutez-vous directement en tant que collaborateur de référentiel. Les pipelines ne peuvent pas voir les membres d’une organisation privée, sauf s’ils sont des collaborateurs directs ou qu’ils appartiennent à une équipe qui est un collaborateur direct. Vous pouvez modifier l’appartenance de votre organisation GitHub de privée à publique ici (remplacez Your-Organization par le nom de votre organisation) : https://github.com/orgs/Your-Organization/people.

Exécutions d’information

Une exécution d’information vous indique qu’Azure DevOps n’a pas pu récupérer le code source d’un pipeline YAML. La récupération du code source se produit en réponse à des événements externes, par exemple, une validation d’envoi (push). Elle se produit également en réponse à des déclencheurs internes, par exemple, pour vérifier s’il existe des modifications de code et démarrer une exécution planifiée ou non. La récupération du code source peut échouer pour plusieurs raisons, notamment la limitation de requêtes par le fournisseur de référentiel Git. L’existence d’une exécution d’informations ne signifie pas nécessairement qu’Azure DevOps allait exécuter le pipeline.

Une exécution d’informations se présente comme dans la capture d’écran suivante.

Vous pouvez reconnaître une exécution d’informations par les attributs suivants :

• L’état est Canceled
• La durée est de < 1s
• Le nom d’exécution contient l’un des textes suivants :
  • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
  • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
  • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
  • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
• Le nom d’exécution contient généralement l’erreur BitBucket /GitHub qui a provoqué l’échec de la charge du pipeline YAML
• Pas de phases/travaux/phases

En savoir plus sur les exécutions d’information.

Checkout

Lorsqu’un pipeline est déclenché, Azure Pipelines extrait votre code source à partir du référentiel Git Azure Repos. Vous pouvez contrôler différents aspects de la façon dont cela se produit.

Version préférée de Git

L’agent Windows est fourni avec sa propre copie de Git. Si vous préférez fournir votre propre Git plutôt que d’utiliser la copie incluse, définissez System.PreferGitFromPath sur true. Ce paramètre a toujours la valeur true sur les agents non Windows.

Chemin de l’extraction

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Sous-modules

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Le pipeline de build vérifie vos sous-modules Git tant qu’ils sont :

• Non authentifié : Dépôt public non authentifié sans informations d’identification requises pour le clonage ou l’extraction.

• Authentifié :

  • Contenu dans le même projet que le référentiel Git Azure Repos spécifié ci-dessus. Les mêmes informations d’identification utilisées par l’agent pour obtenir les sources du référentiel principal sont également utilisées pour obtenir les sources des sous-modules.

  • Ajouté à l’aide d’une URL relative au référentiel principal. Par exemple

    • Celui-ci serait extrait : git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      Dans cet exemple, le sous-module fait référence à un référentiel (FabrikamFiber) dans la même organisation Azure DevOps, mais dans un autre projet (FabrikamFiberProject). Les mêmes informations d’identification utilisées par l’agent pour obtenir les sources du référentiel principal sont également utilisées pour obtenir les sources des sous-modules. Cela nécessite que le jeton d’accès au travail ait accès au référentiel dans le deuxième projet. Si vous avez restreint le jeton d’accès au travail comme expliqué dans la section ci-dessus, vous ne pourrez pas le faire. Vous pouvez autoriser le jeton d’accès au travail à accéder au référentiel dans le deuxième projet (a) en accordant explicitement l’accès au compte de service de build de projet dans le deuxième projet ou (b) à l’aide de jetons d’accès étendus à la collection au lieu de jetons étendus au projet pour l’ensemble de l’organisation. Pour plus d’informations sur ces options et leurs implications en matière de sécurité, consultez Accéder aux référentiels, artefacts et autres ressources.

    • Celui-ci ne serait pas extrait : git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternative à l’utilisation de l’option Extraire les sous-modules

Dans certains cas, vous ne pouvez pas utiliser l’option Extraire les sous-modules. Vous pouvez avoir un scénario dans lequel un autre ensemble d’informations d’identification est nécessaire pour accéder aux sous-modules. Cela peut se produire, par exemple, si votre référentiel principal et vos référentiels de sous-module ne sont pas stockés dans la même organisation Azure DevOps, ou si votre jeton d’accès au travail n’a pas accès au référentiel dans un autre projet.

Si vous ne pouvez pas utiliser l’option Extraire les sous-modules, vous pouvez utiliser une étape de script personnalisée pour extraire les sous-modules. Tout d’abord, obtenez un jeton d’accès personnel (PAT) et préfixez-le avec pat:. Ensuite, encodez cette chaîne préfixée en base64 pour créer un jeton d’authentification de base. Enfin, ajoutez ce script à votre pipeline :

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Veillez à remplacer « <BASE64_ENCODED_STRING> » par votre chaîne « pat:token » encodée en Base64.

Utilisez une variable secrète dans votre projet ou pipeline de build pour stocker le jeton d’authentification de base que vous avez généré. Utilisez cette variable pour remplir le secret dans la commande Git ci-dessus.

Synchroniser les balises

L’étape de validation utilise l’option --tags lors de l’extraction du contenu d’un référentiel Git. Cela entraîne l’extraction par le serveur de toutes les balises ainsi que de tous les objets pointés par ces balises. Cela augmente le temps d’exécution de la tâche dans un pipeline, en particulier si vous avez un grand référentiel avec plusieurs balises. En outre, l’étape d’extraction synchronise les balises même lorsque vous activez l’option d’extraction superficielle, ce qui peut être contraire à son objectif. Pour réduire la quantité de données récupérées ou extraites d’un référentiel Git, Microsoft a ajouté une nouvelle option pour valider le contrôle du comportement des balises de synchronisation. Cette option est disponible à la fois dans les pipelines classiques et YAML.

La synchronisation des balises lors de l’extraction d’un référentiel peut être configurée dans YAML en définissant la propriété fetchTags et dans l’interface utilisateur en configurant le paramètre Balises de synchronisation.

steps:
- checkout: self
  fetchTags: true

Comportement par défaut

• Pour les pipelines existants créés avant la publication d’Azure DevOps sprint 209, publiés en septembre 2022, la valeur par défaut pour la synchronisation des balises reste identique au comportement existant avant l’ajout des options Balises de synchronisation, à savoir true.
• Pour les nouveaux pipelines créés après la version sprint d’Azure DevOps 209, la valeur par défaut pour la synchronisation des balises est false.

Récupération (fetch) superficielle

Vous souhaitez peut-être limiter le nombre de téléchargements dans l’historique. Cela aboutit effectivement à git fetch --depth=n. Si votre dépôt est volumineux, cette option peut rendre votre pipeline de build plus efficace. Votre dépôt peut être volumineux s’il est utilisé depuis longtemps et s’il a un historique important. Il peut également être volumineux si vous avez ajouté et supprimé ultérieurement des fichiers volumineux.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Dans ce cas, cette option peut vous aider à conserver les ressources réseau et de stockage. Cela peut également vous faire gagner du temps. La raison pour laquelle cela n’économise pas toujours du temps est que, dans certaines situations, le serveur peut avoir besoin de passer du temps à calculer les validations à télécharger pour la profondeur que vous spécifiez.

Ne pas synchroniser les sources

Vous souhaiterez peut-être ignorer l’extraction de nouvelles validations. Cette option peut être utile dans les cas où vous souhaitez :

• Utiliser Git init, config et fetch à l’aide de vos propres options personnalisées.

• Utiliser un pipeline de build pour exécuter simplement un travail d’automatisation (par exemple, certains scripts) qui ne dépend pas du code dans le contrôle de version.

steps:
- checkout: none  # Don't sync sources

Nettoyer le build

Vous pouvez effectuer différentes formes de nettoyage du répertoire de travail de votre agent autohébergé avant l’exécution d’un build.

En général, pour des performances plus rapides de vos agents auto-hébergés, ne nettoyez pas le dépôt. Dans ce cas, pour obtenir les meilleures performances, assurez-vous que vous générez également de manière incrémentielle en désactivant toute option Nettoyer de la tâche ou de l’outil que vous utilisez pour générer.

Si vous avez besoin de nettoyer le dépôt (par exemple, pour éviter les problèmes causés par les fichiers résiduels d’une build précédente), vos options sont présentées ci-dessous.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

git clean -ffdx
git reset --hard HEAD

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Étiqueter les sources

Vous pouvez étiqueter vos fichiers de code source pour permettre à votre équipe d’identifier facilement la version de chaque fichier incluse dans la build terminée. Vous avez également la possibilité de spécifier si le code source doit être étiqueté pour tous les builds ou uniquement pour les builds réussis.

Dans Format de balise, vous pouvez utiliser des variables définies par l’utilisateur et prédéfinies qui ont une étendue de « Tout ». Par exemple :

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

Les quatre premières variables sont prédéfinies. Vous pouvez définir My.Variable sous l’onglet Variables.

Le pipeline de build étiquette vos sources avec une étiquette Git.

Certaines variables de build peuvent produire une valeur qui n’est pas une étiquette valide. Par exemple, des variables comme $(Build.RequestedFor) et $(Build.DefinitionName) peuvent contenir des espaces blancs. Si la valeur contient des espaces blancs, l’étiquette n’est pas créée.

Une fois que les sources sont étiquetées par votre pipeline de build, un artefact avec la référence Git refs/tags/{tag} est automatiquement ajouté à la build terminée. Cela offre à votre équipe une traçabilité supplémentaire et un moyen plus convivial de naviguer de la build vers le code qui a été généré. L’étiquette est considérée comme un artefact de build, car elle est produite par la build. Lorsque le build est supprimé manuellement ou via une stratégie de rétention, la balise est également supprimée.

Variables prédéfinies

Lorsque vous générez un référentiel GitHub, la plupart des variables prédéfinies sont disponibles pour vos travaux. Toutefois, étant donné qu’Azure Pipelines ne reconnaît pas l’identité d’un utilisateur effectuant une mise à jour dans GitHub, les variables suivantes sont définies sur l’identité système au lieu de l’identité de l’utilisateur :

• Build.RequestedFor
• Build.RequestedForId
• Build.RequestedForEmail

Mises à jour d’état

Il existe deux types d’états publiés par Azure Pipelines sur GitHub : les états de base et les exécutions de vérification GitHub. La fonctionnalité Vérifications GitHub est disponible uniquement avec les applications GitHub.

Les états du pipeline s’affichent à différents endroits dans l’interface utilisateur GitHub.

• Pour les demandes de tirage, ils sont affichés sous l’onglet Conversations de demande de tirage.
• Pour les validations individuelles, ils sont affichés lors du pointage sur la marque d’état après l’heure de validation sous l’onglet Validations du référentiel.

Connexions PAT ou OAuth GitHub

Pour les pipelines utilisant des connexions PAT ou GitHub OAuth, les états sont renvoyés à la validation/demande de tirage qui a déclenché l’exécution. L’API d’état GitHub est utilisée pour publier ces mises à jour. Ces états contiennent des informations limitées : état du pipeline (échec, réussite), URL pour revenir au pipeline de build et une brève description de l’état.

Les états des connexions PAT ou GitHub OAuth ne sont envoyés qu’au niveau de l’exécution. En d’autres termes, vous pouvez avoir un état unique mis à jour pour une exécution entière. Si vous avez plusieurs travaux dans une exécution, vous ne pouvez pas publier d’état distinct pour chaque travail. Toutefois, plusieurs pipelines peuvent publier des états distincts dans la même validation.

Vérifications GitHub

Pour les pipelines configurés à l’aide de l’application GitHub Azure Pipelines, l’état est publié sous la forme de vérifications GitHub. Les vérifications GitHub permettent d’envoyer des informations détaillées sur l’état et le test du pipeline, la couverture du code et les erreurs. L’API Vérifications GitHub est disponible ici.

Pour chaque pipeline utilisant l’application GitHub, les vérifications sont publiées pour l’exécution globale et chaque travail dans cette exécution.

GitHub autorise trois options quand une ou plusieurs exécutions de vérification échouent pour une demande de tirage/validation. Vous pouvez choisir de « réexécuter » la vérification individuelle, toutes les vérifications ayant échoué sur cette demande/validation, ou toutes les vérifications, qu’elles aient réussi initialement ou non.

En cliquant sur le lien « Réexécuter » à côté du nom Vérifier l’exécution, Azure Pipelines tente à nouveau l’exécution qui a généré l’exécution de vérification. L’exécution résultante aura le même numéro d’exécution et utilisera la même version du code source, de la configuration et du fichier YAML que le build initial. Seuls les travaux qui ont échoué dans l’exécution initiale et tous les travaux en aval dépendants seront réexécutés. Cliquer sur le lien « Réexécuter toutes les vérifications ayant échoué » aura le même effet. Il s’agit du même comportement que de cliquer sur « Nouvelle tentative d’exécution » dans l’interface utilisateur d’Azure Pipelines. Le fait de cliquer sur « Réexécuter toutes les vérifications » entraîne une nouvelle exécution, avec un nouveau numéro d’exécution et récupère les modifications dans la configuration ou le fichier YAML.

Limites

• Pour de meilleures performances, nous recommandons un maximum de 50 pipelines dans un seul dépôt. Pour des performances acceptables, nous recommandons un maximum de 100 pipelines dans un seul dépôt. Le temps nécessaire pour effectuer un envoi (push) vers un référentiel augmente avec le nombre de pipelines de ce dernier. Chaque fois qu’il y a un envoi vers un référentiel, Azure Pipelines doit charger tous les pipelines YAML dans ce référentiel pour déterminer si l’un d’entre eux doit s’exécuter, et le chargement de chaque pipeline entraîne une pénalité de performances. En plus des problèmes de performances, l’utilisation d’un trop grand nombre de pipelines dans un référentiel unique peut entraîner une limitation côté GitHub, car Azure Pipelines peut effectuer trop de requêtes dans un court laps de temps.

• L’utilisation de modèles d'extension et d'inclusion dans un pipeline affecte le taux auquel Azure Pipelines effectue des requêtes d’API GitHub et peut entraîner une limitation côté GitHub. Avant d’exécuter un pipeline, Azure Pipelines doit générer le code YAML complet. Il doit donc extraire tous les fichiers de modèle.

• Azure Pipelines charge un maximum de 2000 branches à partir d’un référentiel dans les listes déroulantes du portail Azure DevOps, par exemple dans la fenêtre Sélectionner une branche pour le paramètre Branche par défaut pour les builds manuels et planifiés, ou lors du choix d’une branche lors de l’exécution d’un pipeline manuellement.

  Si vous ne voyez pas la branche souhaitée dans la liste, tapez manuellement le nom de la branche souhaitée dans le champ Branche par défaut pour les builds manuels et planifiés.

  Si vous cliquez sur l’ellipse et ouvrez le dialogue Sélectionner une branche puis le fermez sans choisir une branche valide dans la liste déroulante, vous pouvez voir un message Certains paramètres nécessitent une attention particulière et un message Ce paramètre est requis sous Branche par défaut pour les builds manuels et planifiés. Pour contourner ce message, rouvrez le pipeline et saisissez directement le nom dans le champ Branche par défaut pour les builds manuels et planifiés.

Forum aux questions

Les problèmes liés à l’intégration de GitHub appartiennent aux catégories suivantes :

• Types de connexion : je ne sais pas quel type de connexion j’utilise pour connecter mon pipeline à GitHub.
• Déclencheurs défaillants : mon pipeline n’est pas déclenché lorsque j’envoie une mise à jour au référentiel.
• Échec de validation : mon pipeline est déclenché, mais il échoue à l’étape de validation.
• Version incorrecte : mon pipeline s’exécute, mais il utilise une version inattendue de la source/YAML.
• Mises à jour d’état manquantes : mes demandes de tirage GitHub sont bloquées, car Azure Pipelines n’a pas signalé de mise à jour d’état.

Types de connexion

Pour résoudre les problèmes de déclencheurs, comment savoir quel type de connexion GitHub j’utilise pour mon pipeline ?

La résolution des problèmes liés aux déclencheurs dépend beaucoup du type de connexion GitHub que vous utilisez dans votre pipeline. Il existe deux façons de déterminer le type de connexion : à partir de GitHub et à partir d’Azure Pipelines.

• À partir de GitHub : si un référentiel est configuré pour utiliser l’application GitHub, les états sur les demandes de tirage et les validations sont Vérifier les exécutions. Si le référentiel dispose d’Azure Pipelines configuré avec des connexions OAuth ou PAT, les états sont le style « ancien » des états. Un moyen rapide de déterminer si les états sont Vérifier les exécutions ou les états simples consiste à examiner l’onglet « conversation » sur une demande de tirage GitHub.

  • Si le lien « Détails » redirige vers l’onglet Vérifications, il s’agit d’une exécution de vérification et le référentiel utilise l’application.
  • Si le lien « Détails » redirige vers le pipeline Azure DevOps, l’état est un état « ancien style » et le référentiel n’utilise pas l’application.

• À partir d’Azure Pipelines : vous pouvez également déterminer le type de connexion en inspectant le pipeline dans l’interface utilisateur d’Azure Pipelines. Ouvrez l’éditeur du pipeline. Sélectionnez Déclencheurs pour ouvrir l’éditeur classique du pipeline. Ensuite, sélectionnez l’onglet YAML, puis l’étape Sources get. Vous remarquerez une bannière Autorisée à l’aide de la connexion : indiquant la connexion de service utilisée pour intégrer le pipeline à GitHub. Le nom de la connexion de service est un lien hypertexte. Sélectionnez-le pour accéder aux propriétés de connexion de service. Les propriétés de la connexion de service indiquent le type de connexion utilisé :

  • L’application Azure Pipelines indique la connexion de l’application GitHub
  • oauth indique la connexion OAuth
  • personalaccesstoken indique l’authentification PAT

Comment changer mon pipeline pour utiliser l’application GitHub au lieu d’OAuth ?

L’utilisation d’une application GitHub au lieu d’une connexion OAuth ou PAT est l’intégration recommandée entre GitHub et Azure Pipelines. Pour passer à l’application GitHub, procédez comme suit :

1. Naviguez ici et installez l’application dans l’organisation GitHub de votre référentiel.
2. Pendant l’installation, vous êtes redirigé vers Azure DevOps pour choisir une organisation et un projet Azure DevOps. Choisissez l’organisation et le projet qui contiennent le pipeline de build classique pour lequel vous souhaitez utiliser l’application. Ce choix associe l’installation de l’application GitHub à votre organisation Azure DevOps. Si vous choisissez incorrectement, vous pouvez visiter cette page pour désinstaller l’application GitHub de votre organisation GitHub et recommencer.
3. Dans la page suivante qui s’affiche, vous n’avez pas besoin de poursuivre avec la création d’un pipeline.
4. Modifiez votre pipeline en accédant à la page Pipelines (par exemple, https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), en sélectionnant votre pipeline, puis en cliquant sur Modifier).
5. S’il s’agit d’un pipeline YAML, sélectionnez le menu Déclencheurs pour ouvrir l’éditeur classique.
6. Sélectionnez l’étape « Sources get » dans le pipeline.
7. Dans la barre verte avec le texte « Autorisé à l’aide de la connexion », sélectionnez « Modifier », puis sélectionnez la connexion d’application GitHub portant le même nom que l’organisation GitHub dans laquelle vous avez installé l’application.
8. Dans la barre d’outils, sélectionnez « Enregistrer et mettre en file d’attente », puis « Enregistrer et mettre en file d’attente ». Sélectionnez le lien vers l’exécution du pipeline qui a été mis en file d’attente pour vous assurer qu’il réussit.
9. Créez (ou fermez et rouvrez) une demande de tirage dans votre référentiel GitHub pour vérifier qu’un build est correctement mis en file d’attente dans sa section « Vérifications ».

Pourquoi aucun référentiel GitHub ne s’affiche-t-il pour me permettre de choisir dans Azure Pipelines ?

Selon le type d’authentification et la propriété du référentiel, des autorisations spécifiques sont requises.

• Si vous utilisez l’application GitHub, consultez Authentification d’application GitHub.
• Si vous utilisez OAuth, consultez Authentification OAuth.
• Si vous utilisez des PAT, consultez Authentification par jeton d’accès personnel (PAT).

Lorsque je sélectionne un référentiel lors de la création du pipeline, j’obtiens une erreur « Le référentiel {nom-du-référentiel} est utilisé avec l’application GitHub Azure Pipelines dans une autre organisation Azure DevOps. »

Cela signifie que votre référentiel est déjà associé à un pipeline dans une autre organisation. Les événements CI et PR de ce référentiel ne fonctionnent pas, car ils seront remis à l’autre organisation. Voici les étapes à suivre pour supprimer le mappage à l’autre organisation avant de procéder à la création d’un pipeline.

1. Ouvrez une demande de tirage (pull request) dans votre référentiel GitHub et faites le commentaire /azp where. Cela renvoie à l’organisation Azure DevOps à laquelle le référentiel est mappé.

2. Pour modifier le mappage, désinstallez l’application de l’organisation GitHub et réinstallez-la. Lorsque vous la réinstallez, veillez à sélectionner la bonne organisation lorsque vous êtes redirigé vers Azure DevOps.

Déclencheurs défaillants

Je viens de créer un pipeline YAML avec des déclencheurs CI/PR, mais le pipeline n’est pas déclenché.

Suivez chacune de ces étapes pour résoudre les problèmes liés à vos déclencheurs défaillants :

• Vos déclencheurs CI ou PR YAML sont-ils remplacés par des paramètres de pipeline dans l’interface utilisateur ? Lors de la modification de votre pipeline, choisissez ... puis Déclencheurs.

  

  Vérifiez le paramètre Remplacer le déclencheur YAML ici pour les types de déclencheurs (intégration continue ou validation de demande de tirage) disponibles pour votre dépôt.

  

• Utilisez-vous la connexion de l’application GitHub pour connecter le pipeline à GitHub ? Consultez Types de connexion pour déterminer le type de connexion dont vous disposez. Si vous utilisez une connexion d’application GitHub, procédez comme suit :

  • Le mappage est-il configuré correctement entre GitHub et Azure DevOps ? Ouvrez une demande de tirage (pull request) dans votre référentiel GitHub et faites le commentaire /azp where. Cela renvoie à l’organisation Azure DevOps à laquelle le référentiel est mappé.

    • Si aucune organisation n’est configurée pour générer ce référentiel à l’aide de l’application, accédez à https://github.com/<org_name>/<repo_name>/settings/installations et terminez la configuration de l’application.

    • Si une autre organisation Azure DevOps est signalée, cela signifie qu’une personne a déjà établi un pipeline pour ce référentiel dans une autre organisation. Nous avons actuellement la limitation nous empêchant de mapper plus d’un référentiel GitHub à une seule organisation DevOps. Seuls les pipelines de la première organisation Azure DevOps peuvent être déclenchés automatiquement. Pour modifier le mappage, désinstallez l’application de l’organisation GitHub et réinstallez-la. Lorsque vous la réinstallez, veillez à sélectionner la bonne organisation lorsque vous êtes redirigé vers Azure DevOps.

• Utilisez-vous OAuth ou PAT pour connecter le pipeline à GitHub ? Consultez Types de connexion pour déterminer le type de connexion dont vous disposez. Si vous utilisez une connexion GitHub, procédez comme suit :

  1. Les connexions OAuth et PAT s’appuient sur des webhooks pour communiquer les mises à jour vers Azure Pipelines. Dans GitHub, accédez aux paramètres de votre référentiel, puis à Webhooks. Vérifiez que les webhooks existent. En règle générale, vous devez voir trois webhooks : push, pull_request et issue_comment. Si ce n’est pas le cas, vous devez recréer la connexion de service et mettre à jour le pipeline pour utiliser la nouvelle connexion de service.

  2. Sélectionnez chacun des webhooks dans GitHub et vérifiez que la charge utile correspondant à la validation de l’utilisateur existe et a été envoyée avec succès à Azure DevOps. Vous pouvez voir une erreur ici si l’événement n’a pas pu être communiqué à Azure DevOps.

• Le trafic d’Azure DevOps peut être limité par GitHub. Quand Azure Pipelines reçoit une notification de GitHub, il tente de contacter GitHub et d’extraire plus d’informations sur le référentiel et le fichier YAML. Si vous disposez d’un référentiel avec un grand nombre de mises à jour et de demandes de tirage, cet appel peut échouer en raison de cette limitation. Dans ce cas, vérifiez si vous pouvez réduire la fréquence des builds à l’aide d’un traitement par lots plus strict/de filtres de branche.

• Votre pipeline est-il suspendu ou désactivé ? Ouvrez l’éditeur du pipeline, puis sélectionnez Paramètres pour vérifier. Si votre pipeline est suspendu ou désactivé, les déclencheurs ne fonctionnent pas.

• Avez-vous mis à jour le fichier YAML dans la branche appropriée ? Si vous envoyez une mise à jour vers une branche, le fichier YAML de cette même branche régit le comportement d’intégration continue. Si vous envoyez une mise à jour vers une branche source, le fichier YAML résultant de la fusion de la branche source avec la branche cible régit le comportement de la demande de tirage. Assurez-vous que le fichier YAML dans la branche appropriée a la configuration CI ou PR nécessaire.

• Avez-vous correctement configuré le déclencheur ? Lorsque vous définissez un déclencheur YAML, vous pouvez spécifier des clauses include et exclude pour les branches, les étiquettes et les chemins d’accès. Vérifiez que la clause include correspond aux détails de votre validation et que la clause exclude ne les exclut pas. Vérifiez la syntaxe des déclencheurs et assurez-vous qu’elle est exacte.

• Avez-vous utilisé des variables pour définir le déclencheur ou les chemins d’accès ? Cela n’est pas pris en charge.

• Avez-vous utilisé des modèles pour votre fichier YAML ? Dans ce cas, assurez-vous que vos déclencheurs sont définis dans le fichier YAML principal. Les déclencheurs définis dans les fichiers de modèle ne sont pas pris en charge.

• Avez-vous exclu les branches ou chemins vers lesquels vous avez envoyé vos modifications ? Testez en envoyant une modification vers un chemin inclus dans une branche incluse. Notez que les chemins d’accès dans les déclencheurs respectent la casse. Veillez à utiliser la même casse que pour les dossiers réels lors de la spécification des chemins d’accès dans les déclencheurs.

• Venez-vous d’envoyer une nouvelle branche ? Dans ce cas, la nouvelle branche peut ne pas démarrer une nouvelle exécution. Consultez la section « Comportement des déclencheurs lors de la création de nouvelles branches ».

Mes déclencheurs CI ou PR fonctionnent bien. Mais ils ont cessé de travailler maintenant.

Tout d’abord, suivez les étapes de résolution des problèmes décrites dans la question précédente, puis procédez comme suit :

• Avez-vous des conflits de fusion dans votre demande de tirage ? Pour une PR qui n’a pas déclenché de pipeline, ouvrez-la et vérifiez si elle a un conflit de fusion. Résoudre le conflit de fusion.

• Rencontrez-vous un retard dans le traitement des événements d’envoi ou de demande de tirage ? Vous pouvez généralement vérifier un délai en regardant si le problème est spécifique à un pipeline unique ou s’il est commun à tous les pipelines ou référentiels de votre projet. Si une mise à jour d’envoi ou de demande de tirage dans l’un des dépôts présente ce symptôme, nous pouvons rencontrer des retards dans le traitement des événements de mise à jour. Voici quelques raisons pour lesquelles un retard peut se produire :

  • Nous avons une panne de service dans notre page d’état. Si la page d’état affiche un problème, notre équipe a probablement déjà commencé à travailler dessus. Consultez fréquemment la page pour obtenir des mises à jour sur le problème.
  • Votre dépôt contient trop de pipelines YAML. Pour de meilleures performances, nous recommandons un maximum de 50 pipelines dans un seul dépôt. Pour des performances acceptables, nous recommandons un maximum de 100 pipelines dans un seul dépôt. Plus il y a de pipelines, plus le traitement d’un envoi push vers ce dépôt est lent. Chaque fois qu’il y a un envoi push vers un dépôt, Azure Pipelines doit charger tous les pipelines YAML dans ce référentiel pour déterminer si l’un d’eux doit s’exécuter, et chaque nouvelle pipeline entraîne une pénalité de performances.

Je ne souhaite pas que les utilisateurs remplacent la liste des branches pour les déclencheurs lorsqu’ils mettent à jour le fichier YAML. Comment procéder ?

Les utilisateurs disposant des autorisations nécessaires pour contribuer au code peuvent mettre à jour le fichier YAML et inclure/exclure des branches supplémentaires. Par conséquent, les utilisateurs peuvent inclure leur propre fonctionnalité ou branche utilisateur dans leur fichier YAML et envoyer cette mise à jour vers une branche de fonctionnalité ou utilisateur. Cela peut entraîner le déclenchement du pipeline pour toutes les mises à jour de cette branche. Si vous souhaitez empêcher ce comportement, vous pouvez :

1. Modifier le pipeline dans l’interface utilisateur Azure Pipelines.
2. Accédez au menu Déclencheurs.
3. Sélectionnez Remplacer le déclencheur d’intégration continue YAML à partir d’ici.
4. Spécifiez les branches à inclure ou à exclure pour le déclencheur.

Lorsque vous suivez ces étapes, tous les déclencheurs CI spécifiés dans le fichier YAML sont ignorés.

Échec de la validation

L’erreur suivante s’affiche dans le fichier journal lors de l’étape de validation. Comment la corriger ?

remote: Repository not found.
fatal: repository <repo> not found

Cela peut être dû à une panne de GitHub. Essayez d’accéder au référentiel dans GitHub et vérifiez que vous êtes en mesure de le faire.

Version erronée

Une version incorrecte du fichier YAML est utilisée dans le pipeline. Pourquoi ?

• Pour les déclencheurs CI, le fichier YAML qui se trouve dans la branche que vous envoyez est évalué pour voir si une build CI doit être exécutée.
• Pour les déclencheurs de demande de tirage, le fichier YAML résultant de la fusion des branches source et cible de la demande de tirage est évalué pour voir si un build de demande de tirage doit être exécuté.

Mises à jour d’état manquantes

Ma demande de tirage dans GitHub est bloquée, car Azure Pipelines n’a pas mis à jour l’état.

Il peut s’agir d’une erreur temporaire qui a entraîné l’impossibilité pour Azure DevOps de communiquer avec GitHub. Réessayez d’archiver GitHub si vous utilisez l’application GitHub. Ou faites une mise à jour triviale de la demande de tirage pour voir si le problème peut être résolu.

Articles connexes

• Déclencheurs planifiés
• Déclencheurs d’achèvement de pipeline