Générer des dépôts Git Azure Repos ou Git TFS

Vous pouvez également indiquer à Azure Pipelines d’ignorer l’exécution d’un pipeline déclenchée normalement par une poussée. Il suffit d’inclure ***NO_CI*** dans le message d’un des commits qui font partie de la poussée, et Azure Pipelines ignore l’exécution CI pour cette poussée.

Vous pouvez également indiquer à Azure Pipelines d’ignorer l’exécution d’un pipeline déclenchée normalement par une poussée. 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***

Valider les contributions des duplications

La génération de demandes de tirage à partir de duplications Azure Repos n’est pas différente de la génération de demandes de tirage au sein du même dépôt ou projet. Vous pouvez créer des duplications seulement dans l’organisation dont votre projet fait partie.

Limiter l’étendue d’autorisation du travail

Azure Pipelines fournit plusieurs paramètres de sécurité pour configurer l’étendue d’autorisation du travail dans laquelle vos pipelines s’exécutent.

• Limiter l’étendue d’autorisation du travail au projet actuel
• Protéger l’accès aux dépôts dans les pipelines YAML

Limiter l’étendue d’autorisation du travail au projet actuel

Azure Pipelines fournit deux paramètres Limiter l’étendue d’autorisation du travail au projet actuel :

• Limiter l’étendue d’autorisation du travail au projet actuel pour les pipelines hors mise en production : ce paramètre s’applique aux pipelines YAML et aux pipelines de build classiques. Il ne s’applique pas aux pipelines de mise en production classiques.
• Limiter l’étendue d’autorisation du travail au projet actuel pour les pipelines de mise en production : ce paramètre s’applique uniquement aux pipelines de mise en production classiques.

Les pipelines s’exécutent avec des jetons d’accès étendus à la collection, sauf si le paramètre approprié pour le type de pipeline est activé. Les paramètres Limiter l’étendue d’autorisation du travail vous permettent de réduire l’étendue d’accès de tous les pipelines au projet actuel. Cela peut impacter votre pipeline si vous accédez à un dépôt Git Azure Repos dans un autre projet de votre organisation.

Si votre dépôt Git Azure Repos est dans un projet différent de celui de votre pipeline et que le paramètre Limiter l’étendue d’autorisation du travail pour votre type de pipeline est activé, vous devez accorder l’autorisation à l’identité de service de build pour votre pipeline sur le deuxième projet. Pour plus d’informations, consultez Gérer les autorisations de compte de service de build.

Azure Pipelines fournit un paramètre de sécurité pour configurer l’étendue d’autorisation du travail dans laquelle vos pipelines s’exécutent.

• Limiter l’étendue d’autorisation du travail au projet actuel : ce paramètre s’applique aux pipelines YAML et aux pipelines de build classiques. Il ne s’applique pas aux pipelines de mise en production classiques.

Les pipelines s’exécutent avec des jetons d’accès étendus à la collection, sauf si l’option Limiter l’étendue d’autorisation du travail au projet actuel est activée. Ce paramètre vous permet de réduire l’étendue d’accès de tous les pipelines au projet actuel. Cela peut impacter votre pipeline si vous accédez à un dépôt Git Azure Repos dans un autre projet de votre organisation.

Si votre dépôt Git Azure Repos est dans un projet différent de celui de votre pipeline et que le paramètre Limiter l’étendue d’autorisation du travail est activé, vous devez accorder l’autorisation à l’identité de service de build pour votre pipeline sur le deuxième projet. Pour plus d’informations, consultez Étendue d’autorisation de travail.

Pour plus d’informations sur Limiter l’étendue d’autorisation du travail, consultez Comprendre les jetons d’accès du travail.

Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés

Les pipelines peuvent accéder à n’importe quel dépôt Azure DevOps dans les projets autorisés, comme décrit dans la section précédente Limiter l’étendue d’autorisation du travail au projet actuel, sauf si l’option Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés est activée. Quand cette option est activée, vous pouvez réduire l’étendue d’accès de tous les pipelines aux seuls dépôts Azure DevOps explicitement référencés par une étape checkout ou une instruction uses dans le travail de pipeline qui utilise ce dépôt.

Pour configurer ce paramètre, accédez à Pipelines, Paramètres dans Paramètres de l’organisation ou Paramètres du projet. S’il est activé au niveau de l’organisation, le paramètre est grisé et indisponible dans les paramètres du projet.

Quand Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés est activé, vos pipelines YAML doivent explicitement référencer tous les dépôts Git Azure Repos que vous voulez utiliser dans le pipeline comme étape d’extraction dans le travail qui utilise le dépôt. Vous ne pouvez pas récupérer le code avec des tâches de script et des commandes git pour un dépôt Git Azure Repos, sauf si ce dépôt est d’abord référencé explicitement.

Dans certains cas, vous n’avez pas besoin de référencer explicitement un dépôt Git Azure Repos avant de l’utiliser dans votre pipeline quand Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés est activé.

• Si vous n’avez pas d’étape d’extraction explicite dans votre pipeline, c’est comme si vous aviez une étape checkout: self et que le dépôt self était extrait.
• Si vous utilisez un script pour effectuer des opérations en lecture seule sur un dépôt dans un projet public, vous n’avez pas besoin de référencer le dépôt du projet public dans une étape checkout.
• Si vous utilisez un script qui fournit sa propre authentification au dépôt, par exemple, un jeton PAT, vous n’avez pas besoin de référencer ce dépôt dans une étape checkout.

Par exemple, quand Limiter l’étendue d’autorisation du travail aux dépôts Azure DevOps référencés est activé, si votre pipeline est dans le dépôt FabrikamProject/Fabrikam de votre organisation et que vous voulez utiliser un script pour extraire le dépôt FabrikamProject/FabrikamTools, vous devez référencer ce dépôt dans une étape checkout ou avec une instruction uses.

Si vous extrayez déjà le dépôt FabrikamTools dans votre pipeline avec une étape d’extraction, vous pouvez ensuite utiliser des scripts pour interagir avec ce dépôt.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

Protéger l’accès aux dépôts dans les pipelines YAML

Les pipelines peuvent accéder à n’importe quel dépôt Azure DevOps dans les projets autorisés, comme décrit dans la section précédente Limiter l’étendue d’autorisation du travail au projet actuel, sauf si Protéger l’accès aux dépôts dans les pipelines YAML est activé. Quand cette option est activée, vous pouvez réduire l’étendue d’accès de tous les pipelines aux seuls dépôts Azure DevOps explicitement référencés par une étape checkout ou une instruction uses dans le travail de pipeline qui utilise ce dépôt.

Pour configurer ce paramètre, accédez à Pipelines, Paramètres dans Paramètres de l’organisation ou Paramètres du projet. S’il est activé au niveau de l’organisation, le paramètre est grisé et indisponible dans les paramètres du projet.

Dans certains cas, vous n’avez pas besoin de référencer explicitement un dépôt Git Azure Repos avant de l’utiliser dans votre pipeline si Protéger l’accès aux dépôts dans les pipelines YAML est activé.

• Si vous n’avez pas d’étape d’extraction explicite dans votre pipeline, c’est comme si vous aviez une étape checkout: self et que le dépôt self était extrait.
• Si vous utilisez un script pour effectuer des opérations en lecture seule sur un dépôt dans un projet public, vous n’avez pas besoin de référencer le dépôt du projet public dans une étape checkout.
• Si vous utilisez un script qui fournit sa propre authentification au dépôt, par exemple, un jeton PAT, vous n’avez pas besoin de référencer ce dépôt dans une étape checkout.

Par exemple, quand Protéger l’accès aux dépôts dans les pipelines YAML est activé, si votre pipeline est dans le dépôt FabrikamProject/Fabrikam de votre organisation et que vous voulez utiliser un script pour extraire le dépôt FabrikamProject/FabrikamTools, vous devez référencer ce dépôt dans une étape checkout ou avec une instruction uses.

Si vous extrayez déjà le dépôt FabrikamTools dans votre pipeline avec une étape d’extraction, vous pouvez ensuite utiliser des scripts pour interagir avec ce dépôt.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

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. Quand la build est supprimée manuellement ou par une stratégie de conservation, l’étiquette est également supprimée.