У меня есть репо под моей учетной записью VSTS почти более 6 месяцев. Я использую частного агента для его создания. До вчерашнего дня он использовал путь C:\agent\_work\13 при создании репо. С сегодняшнего дня он внезапно создал новый каталог в C:\agent\_work\201 и попытался собрать проект. Что может быть причиной этого?
Вот как моя текущая структура каталогов выглядит на частном агенте.
Исходные корневые сопоставления:
Дайте мне знать, если кто-нибудь знает, как решить эту проблему.
Это не проблема, нет ничего неправильного или нужного «исправить».
Определение сборки могло быть удалено и создано заново (или клонировано, а затем удалено исходное), что привело к тому, что оно начало использовать новую папку. Каждое определение сборки получает уникальную папку для каждого агента сборки.
Вы не должны полагаться на то, что сборка заканчивается в каком-либо конкретном месте. Если вы в настоящее время делаете это, вы делаете неверное предположение и должны начать использовать встроенные переменные (например, $(Build.SourcesDirectory)), которые позволяют вам прозрачно ссылаться на рабочую папку сборки.
В рабочей папке есть папка SourceRootMapping, а в этой папке есть файлы Mappings.json и SourceFolder.json (SourceRootMapping{guid} folder{build definition id} folder\sourceFolder.json).
Итак, проверьте lastBuildFolderNumber в файле Mappings.json и SourceFolder.json на наличие существующего сопоставления.
Вы можете очистить папку _work.
Связанная тема: Увеличение в каталоге _work
{ "lastBuildFolderCreatedOn": "05/22/2018 16:43:10 -07:00", "lastBuildFolderNumber": 205 }
- person tRuEsatm; 23.05.2018
Я знаю, что это старый вопрос, но я был разочарован тем же и немного покопался в первопричине.
ЛЮБОЕ изменение URL-адреса репо, по-видимому, создает новую рабочую папку. Если имя репозитория, имя проекта или имя организации/коллекции изменяется, изменится URL-адрес репозитория, который затем порождает новый SourceFolder.json для этого определения/конвейера сборки в папке SourceRootMapping. Используется последний файл SourceFolder.json.
Вы можете проверить папку SourceRootMapping и попытаться найти папку definitionId рабочей папки, которая была заменена более новой. Если у вас есть несколько папок в этом каталоге definitionId, проверьте файлы SourceFolder.json внутри них и посмотрите, что изменилось, какие изменения привели к созданию и использованию новой папки.
Пример. Мой каталог D:\ADO-Terraform\_work\SourceRootMapping\542dccee-a265-44db-bae0-9b3f48d21793\1837, где 1837 является definitionID (не совпадает с номером рабочей папки), содержит 4 папки с именами hashKey под ним. У меня был 1, который был моим оригиналом, затем 1, когда я изменил используемое репо, затем 1, когда я переименовал используемое репо, затем 1, когда я переименовал проект, в котором была эта работа.
К сожалению, я не думаю, что есть способ исправить это, чтобы использовать старую папку. Но, как сказал кто-то другой, вы можете очистить рабочую папку от всех папок, помеченных определением сборки (1-201 в вашем примере), а затем сбросить/очистить файл mappings.json, что должно сделать ваш агент начинает с 1.
Прежде чем я получу ответ, это не должно иметь значения или использовать системные переменные: мне нужно, чтобы агент использовал один и тот же каталог для каждой сборки, потому что я использую Terraform для развертывания некоторых простых файлов в нашем балансировщике нагрузки; Terraform использует файлы состояния. Если файл состояния не существует (например, когда агент использует другую рабочую папку), Terraform пытается создать файл как новый на нашем балансировщике нагрузки, что вызывает ошибку «файл уже существует».
