Générer des dépôts TFVC

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Important

TFVC est pris en charge uniquement par les pipelines classiques et ne prend pas en charge YAML.

Choisir le référentiel à générer

Lors de la modification d’un pipeline qui utilise un référentiel TFVC, vous disposez des options suivantes.

• Clean
• Spécifier le chemin d’accès local
• Étiqueter les sources

Nom du dépôt

Nom du référentiel TFVC.

Mappages (espace de travail)

Incluez avec une valeur de type Mappage uniquement les dossiers dont votre pipeline de build a besoin. Si un sous-dossier d’un dossier mappé contient des fichiers non requis par le pipeline de build, affectez-lui la valeur de type Masquer.

Prenez soin de mapper tous les dossiers qui contiennent les fichiers requis par votre pipeline de build. Par exemple, si vous ajoutez un autre projet, vous devrez peut-être ajouter un autre mappage à l’espace de travail.

Les dossiers Masquer dont vous n’avez pas besoin. Par défaut, le dossier racine du projet est mappé dans l’espace de travail. Dans cette configuration, l’agent de build télécharge tous les fichiers du dossier de contrôle de version de votre projet. Si ce dossier contient de nombreuses données, votre build est susceptible de gaspiller des ressources du système de génération et de ralentir votre pipeline de build en téléchargeant de grandes quantités de données dont elle n’a pas besoin.

Lorsque vous supprimez des projets, recherchez les mappages que vous pouvez supprimer de l’espace de travail.

S’il s’agit d’une build CI, dans la plupart des cas, vous devez vous assurer que ces mappages correspondent aux paramètres de filtre de votre déclencheur CI sous l’onglet Déclencheurs.

Pour plus d’informations sur l’optimisation d’un espace de travail TFVC, consultez Optimiser votre espace de travail.

Nettoyer le référentiel local sur l’agent

Vous pouvez effectuer différentes formes de nettoyage du répertoire de travail de votre agent auto-hébergé avant l’exécution d’une 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.

Notes

Le nettoyage n’est pas pertinent si vous utilisez un agent hébergé par Microsoft, car vous obtenez un nouvel agent à chaque fois dans ce cas.

Si vous souhaitez propre le référentiel, sélectionnez true, puis sélectionnez l’une des options suivantes :

• Sources : le pipeline de build annule toutes les modifications et exécute l’espace de travail actuel sous $(Build.SourcesDirectory).

• Sources et répertoire de sortie : même opération que l’option Sources ci-dessus, plus : supprime et recrée $(Build.BinariesDirectory).

• Répertoire des sources : supprime et recrée $(Build.SourcesDirectory).

• Tous les répertoires de build : supprime et recrée $(Agent.BuildDirectory).

Déclencheurs CI

Sélectionnez Activer l’intégration continue sous l’onglet Déclencheurs pour activer ce déclencheur si vous souhaitez que la build s’exécute chaque fois qu’une personne archive du code.

Modifications par lots

Activez cette case à cocher si vous avez de nombreux membres de l’équipe qui chargent souvent des modifications et que vous souhaitez réduire le nombre de builds que vous exécutez. Si vous sélectionnez cette option, quand une build s’exécute, le système attend que la build soit terminée, puis met en file d’attente une autre build de tous les changements qui n’ont pas encore été générés.

Vous pouvez effectuer des modifications par lot et les générer ensemble.

Filtres de chemin

Sélectionnez les chemins d’accès de contrôle de version que vous souhaitez inclure et exclure. Dans la plupart des cas, vous devez vous assurer que ces filtres sont cohérents avec vos mappages TFVC. Vous pouvez utiliser des filtres de chemin d’accès pour réduire l’ensemble des fichiers que vous souhaitez déclencher une build.

Conseils :

• Les chemins d’accès sont toujours spécifiés par rapport à la racine de l’espace de travail.
• Si vous ne définissez pas de filtres de chemin d’accès, le dossier racine de l’espace de travail est implicitement inclus par défaut.
• Si vous excluez un chemin d’accès, vous ne pouvez pas l’inclure, sauf si vous le qualifiez pour un dossier plus profond. Par exemple, si vous excluez /tools, vous pouvez inclure /tools/trigger-runs-on-these
• L’ordre des filtres de chemin d’accès n’a pas d’importance.

Archivage contrôlé

Vous pouvez utiliser l’archivage contrôlé pour vous protéger contre les changements cassants.

Par défaut, l’option Utiliser les mappages d’espace de travail pour les filtres est sélectionnée. Les builds sont déclenchées chaque fois qu’une modification est enregistrée sous un chemin spécifié dans vos mappages de source.

Sinon, vous pouvez supprimer cette case à cocher et spécifier les chemins d’accès dans le déclencheur.

Comment cela affecte vos développeurs

Lorsque les développeurs essaient d’archiver, ils sont invités à générer leurs modifications.

Le système crée ensuite un jeu de réservations et le crée.

Notes

Si vous recevez une erreur comme The shelveset _Build_95;Build\6bc8a077-3f27-4936-82e6-415fbd53ba07 could not be found for check-in, vérifiez le paramètre Limiter l’étendue d’autorisation du travail au projet actif pour les pipelines sans mise en production et assurez-vous qu’il n’est pas activé.

Pour plus d’informations sur l’expérience d’archivage contrôlé, consultez Archiver dans un dossier contrôlé par un pipeline de build d’archivage contrôlé.

Option permettant d’exécuter des builds CI

Par défaut, les builds CI ne sont pas exécutées une fois le processus d’archivage contrôlé est terminé et les modifications sont archivées.

Toutefois, si vous souhaitez que les builds CI s’exécutent après un archivage contrôlé, cochez la case Exécuter les déclencheurs CI pour les modifications validées. Dans ce cas, le pipeline de build n’ajoute pas ***NO_CI*** à la description de l’ensemble de modifications. Par conséquent, les builds CI affectées par l’archivage sont exécutées.

Quelques autres choses à connaître

• Assurez-vous que les dossiers que vous incluez dans votre déclencheur sont également inclus dans vos mappages d’espace de travail.
• Vous pouvez exécuter des builds contrôlées sur un agent hébergé par Microsoft ou sur un agent auto-hébergé.

Questions fréquentes (FAQ)

Je reçois l’erreur suivante lors de l’exécution d’un pipeline :

The shelveset <xyz> could not be found for check-in

• L’étendue d’autorisation de votre travail est-elle définie sur collection ? Les référentiels TFVC sont généralement répartis entre les projets de votre collection. Vous pouvez lire ou écrire dans un dossier accessible uniquement lorsque l’étendue est la collection entière. Vous pouvez le définir dans les paramètres d’organisation ou dans le paramètre de projet sous l’onglet Pipelines.

Je reçois l’erreur suivante lors de l’exécution d’un pipeline :

The underlying connection was closed: An unexpected error occurred on a receive. ##[error]Exit code 100 returned from process: file name 'tf', arguments 'vc workspace /new /location:local /permission:Public

• Il s’agit généralement d’une erreur intermittente provoquée lorsque le service rencontre des problèmes techniques. Réexécutez le pipeline.

Qu’est-ce que le scorch ?

Scorch est un outil d’alimentation TFVC qui garantit que le contrôle de code source sur le serveur et le disque local sont identiques. Consultez Microsoft Visual Studio Team Foundation Server 2015 Power Tools.