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

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

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

Lors de la modification d’un pipeline qui utilise un dépôt TFVC, vous disposez des options suivantes.

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

Nom du référentiel

Nom du référentiel TFVC.

Mappages (espace de travail)

Incluez avec une valeur de type de Mapper uniquement les dossiers dont votre pipeline de build a besoin. Si un sous-dossier d’un dossier mappé contient des fichiers dont le pipeline de build ne nécessite pas, mappez-le avec une valeur de type de Cloak.

Assurez-vous que vous Mapper tous les dossiers qui contiennent des fichiers dont votre pipeline de build a besoin. Par exemple, si vous ajoutez un autre projet, vous devrez peut-être ajouter un autre mappage à l’espace de travail.

dossiers dont vous n’avez pas besoin. Par défaut, le dossier racine du projet est mappé dans l’espace de travail. Cette configuration entraîne le téléchargement de tous les fichiers dans le dossier de contrôle de version de votre projet. Si ce dossier contient beaucoup de données, votre build peut gaspiller les ressources système et ralentir votre pipeline de build en téléchargeant de grandes quantités de données qu’il ne nécessite pas.

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 dépôt local sur l’agent

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.

Si vous souhaitez nettoyer le dépôt, sélectionnez true, puis sélectionnez l’une des options suivantes :

• Sources: le pipeline de build effectue une annulation de toutes les modifications et remplit 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 le 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, lorsqu’une build est en cours d’exécution, le système attend que la build soit terminée, puis met en file d’attente une autre build de toutes les modifications qui n’ont pas encore été générées.

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

Filtres de chemin

Sélectionnez les chemins 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 de 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.

Check-in 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 décocher 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 de s’archiver, ils sont invités à générer leurs modifications.

Le système crée ensuite un ensemble d’étagères et le génère.

Pour plus d’informations sur l’expérience d’archivage contrôlée, consultez Archiver dans un dossier contrôlé par un pipeline de build de contrôle 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é terminé et les modifications sont archivées.

Toutefois, si vous voulez que les builds CI s’exécutent après une vérification contrôlée, cochez la case Exécuter les déclencheurs CI pour les modifications validées case à cocher. Lorsque vous effectuez cette opération, 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

• Vérifiez 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 un agent auto-hébergé .

Questions fréquentes (FAQ)

J’obtiens l’erreur suivante lors de l’exécution d’un pipeline :

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

• Votre étendue d’autorisation de travail est-elle définie sur de collecte ? Les dépôts 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 définir cela dans les paramètres de l’organisation ou dans le paramètre de projet sous l’onglet Pipelines.

J’obtiens 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 qu’un 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.