Поделиться через

Устранение неполадок при запуске конвейера

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

Если выполнение конвейера завершится сбоем, используйте диагностические сведения и журналы на странице сводки запуска конвейера, чтобы устранить проблему. В этом руководстве приведены инструкции по диагностике сбоев конвейера с помощью журналов, средств анализа ошибок и распространенных методов устранения неполадок. Узнайте, как определить первопричины и реализовать решения, чтобы обеспечить плавность работы конвейеров.

Снимок экрана: страница сводки запуска конвейера с диагностическими сведениями.

Просмотр журналов

Выберите сообщение об ошибке, чтобы просмотреть журналы для задачи, которая не завершена.

Снимок экрана: сообщение об ошибке задачи на странице сводки запуска конвейера.

На странице журналов отображается выбранная ошибка. В этом примере в задаче cmd-line возникает ошибка, в которой команда echo вводится как ech.

Снимок экрана: журнал диагностики для запуска конвейера.

Вы можете просмотреть необработанный журнал для задачи, выбрав "Просмотреть необработанный журнал" и выполнить поиск по журналу с помощью поиска.

Снимок экрана: параметры представления журнала в Azure DevOps.

Проверьте журналы неудачной задачи для получения сведений об ошибках и подсказках о том, почему задача завершается ошибкой. По умолчанию выполнение конвейера генерирует журналы с минимальным уровнем детализации. Если журналы по умолчанию не указывают причину проблемы, вы можете получить дополнительные сведения, настроив подробные журналы.

Страница анализа ошибок

Помощь по устранению неполадок доступна на странице анализа ошибок . Переместите указатель мыши на строку сведений об ошибке и выберите значок анализа представления .

Снимок экрана: значок анализа представления на странице сводки запуска конвейера.

Снимок экрана: значок анализа представления для Azure DevOps Server.

Выберите «Просмотреть агент» для локальных агентов (или О размещённых агентах Майкрософт для агентов, размещённых Майкрософт), чтобы просмотреть дополнительные сведения об агенте, используемом для запуска конвейера, и Просмотр журнала для просмотра логов выполнения конвейера.

Снимок экрана: страница анализа ошибок на портале Azure DevOps.

Выберите имя задачи под сведениями о времени выполнения , чтобы просмотреть сведения о задаче.

Снимок экрана: сведения о задаче из анализа ошибок.

В этом примере вы можете увидеть, что есть ошибка в ValueScript. Выберите "Об этой задаче" , чтобы просмотреть документацию для задачи.

Если проблема не отображается на странице сводки запуска конвейера или просмотре журналов, проверьте следующий раздел распространенных проблем и просмотрите журналы для диагностики проблем конвейера для получения сведений о скачивании полных журналов, включающих дополнительные диагностические сведения.

Распространенные проблемы

Аналитика задач для неудачных запусков конвейера

Azure DevOps предоставляет параметр "Аналитика задач для неудачных запусков конвейера ", который при включении предоставляет всплывающие уведомления о сбоях сборки со ссылкой для просмотра отчета.

Снимок экрана: метрики аналитики задач.

Чтобы настроить этот параметр, перейдите к функциям предварительной версии, найдите аналитику задач для неудачных запусков конвейера и выберите нужный параметр.

Снимок экрана: аналитические сведения о задачах для параметра неудачных запусков конвейера.

Уведомления о неудачных запусках

Azure DevOps включает встроенные уведомления о сбоях в работе конвейера. Чтобы включить уведомления, выполните приведенные действия.

  1. Перейдите в Настройки проекта>Уведомления для вашего проекта.
  2. Выберите тип уведомления, которое вы хотите получить. Чтобы получать уведомления при каждом сбое выполнения сборки, выберите сбой сборки.

Снимок экрана: уведомления в параметрах проекта.

Перед продолжением выполнения этого конвейера требуется разрешение на доступ к ресурсу.

Если ваш конвейер не запускается или вы получаете сообщение об ошибке типа This pipeline needs permission to access a resource before this run can continue, проверьте, не ожидает ли конвейер авторизации от ресурса, например служебного соединения или пула агентов.

  1. Перейдите к конвейеру и вручную запустите запуск.
  2. Появляется сообщение Этот конвейер должен иметь разрешение на доступ к ресурсу, прежде чем этот запуск сможет продолжиться. Выберите "Вид " рядом с сообщением.
  3. На экране "Ожидание проверки " выберите "Разрешение" и на экране подтверждения снова нажмите кнопку "Разрешить ".

Это действие явно добавляет конвейер в качестве авторизованного пользователя ресурса.

Существует два способа предоставления доступа пайплайнам к пулу агентов.

Авторизация определенных конвейеров

Вы можете авторизовать конкретные конвейеры по отдельности для их запуска в пуле агентов, следуя процедуре в предыдущем разделе при получении сообщения, как This pipeline needs permission to access a resource before this run can continue.

Вы также можете вручную добавлять и удалять конвейеры из авторизованного списка, выполнив следующую процедуру. Эта процедура выполняется на уровне проекта в организации Azure DevOps.

  1. В Azure DevOps перейдите в раздел "Параметры проекта", пулы агентов, выберите локальный пул и выберите "Безопасность".
  2. Выберите + , чтобы добавить конвейер в авторизованный список.
  3. Выберите X(Отменить доступ), чтобы удалить конвейер из авторизованного списка.

Настройка открытого доступа

Некоторые ресурсы позволяют настроить открытый доступ , чтобы каждое новое определение конвейера не требовало явной авторизации.

Для настройки Open Access требуются разрешения администратора проекта .

Чтобы настроить открытый доступ для пулов агентов, выполните приведенные выше действия.

  1. В Azure DevOps перейдите в раздел "Параметры проекта", пулы агентов, выберите локальный пул и выберите "Безопасность".
  2. Выберите "Дополнительные действия", "Открыть доступ", чтобы включить открытый доступ, и нажмите кнопку "Открыть доступ " еще раз, чтобы подтвердить.
  3. Чтобы отменить открытый доступ, выберите "Ограничить разрешение".

Чтобы узнать, доступен ли open access для других типов ресурсов, см. статью "Управление безопасностью в Azure Pipelines " и поиск открытого доступа.

Дополнительные сведения о открытом доступе для пулов агентов см. в разделе Настройка разрешений конвейера для отдельного пула агентов и разрешений конвейера.

Превышено время выполнения задания

Конвейер может выполняться в течение длительного времени, а затем завершается сбоем из-за времени ожидания задания. Время ожидания задания тесно зависит от используемого агента. Бесплатные агенты, размещаемые Майкрософт, имеют максимальный таймаут в 60 минут на каждое задание для частного репозитория и 360 минут для публичного репозитория.

Чтобы увеличить максимальное время ожидания для задания, можно выбрать любой из следующих вариантов.

  • Купите облачного агента Майкрософт, который предоставляет 360 минут для всех заданий, независимо от используемого репозитория.
  • Используйте самостоятельно размещенный агент, чтобы исключить любые проблемы с тайм-аутом, связанные с работой агента.

Дополнительные сведения о тайм-ауте задания.

Примечание.

Если время выполнения заданий агента, размещенного на платформе Microsoft, истекает, убедитесь, что время ожидания вашего пайплайна установлено больше максимального времени ожидания для задания. Чтобы проверить время ожидания, см. раздел "Время ожидания".

Проблемы с скачиванием кода

Сбой конвейера на этапе чекаута

Если вы используете checkout шаг в репозитории Azure Repos Git вашей организации, который находится в проекте, отличном от вашего конвейера, убедитесь, что настройка Ограничить область авторизации задания текущим проектом отключена, или выполните шаги, описанные в Идентификаторы сборки с ограниченной областью, чтобы убедиться, что ваш конвейер имеет доступ к репозиторию.

Если конвейер не может получить доступ к репозиторию из-за ограниченной области авторизации задания, вы получите ошибку Git fetch failed with exit code 128 , а журналы содержат запись, аналогичную Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.

Если конвейер моментально завершается сбоем с Could not find a project that corresponds with the repository, убедитесь, что имя проекта и репозитория правильно на шаге checkout или в декларации ресурса репозитория.

Проблемы управления версиями Team Foundation (TFVC)

Получение источников, не скачивая некоторые файлы

В журнале может появиться сообщение от команды tf get: «Все файлы обновлены». Убедитесь, что встроенный идентификатор службы имеет разрешение на скачивание источников. Либо удостоверению службы сборки коллекции проектов, либо удостоверению службы сборки проекта требуется разрешение на скачивание источников в зависимости от выбранной области авторизации на вкладке "Общие" конвейера сборки. В пользовательском веб-интерфейсе управления версиями можно просматривать файлы проекта на любом уровне иерархии папок и проверять параметры безопасности.

Получение источников с помощью прокси-сервера Team Foundation

Самый простой способ настроить агент для получения источников через прокси-сервер Team Foundation — задать переменную среды TFSPROXY, которая указывает на прокси-сервер TFVC для запуска от имени пользователя агента.

Виндоус:

    set TFSPROXY=http://tfvcproxy:8081
    setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable

Mac OS и Linux:

    export TFSPROXY=http://tfvcproxy:8081

Мой конвейер выходит из строя на шаге командной строки, например, MSBUILD.

Полезно уточнить, является ли сбой сборки или релиза результатом проблемы с продуктом Azure Pipelines (агентом или задачами). Сбои сборки и выпуска могут также происходить из-за внешних команд.

Проверьте журналы, чтобы найти точную командную строку, выполненную неудавшейся задачей. Попытка выполнить команду локально из командной строки может воспроизвести проблему. Это может быть полезно для локального выполнения команды с собственного компьютера и (или) входа на компьютер и выполнения команды в качестве учетной записи службы.

Например, проблема возникает во время части конвейера сборки MSBuild (например, вы используете задачу MSBuild или Visual Studio Build )? Если да, попробуйте выполнить ту же команду MSBuild на локальном компьютере, используя те же аргументы. Если вы можете воспроизвести проблему на локальном компьютере, выполните следующие действия, чтобы изучить проблему MSBuild .

Макет файла

Расположение средств, библиотек, заголовков и других элементов, необходимых для сборки, может быть другим на размещенном агенте по сравнению с локальной машиной. Если сборка завершается ошибкой, так как она не может найти один из этих файлов, можно использовать приведенные ниже скрипты для проверки макета агента. Это может помочь вам отслеживать отсутствующий файл.

Создайте новый конвейер YAML во временном расположении (например, новый репозиторий, созданный для устранения неполадок). Как было написано, скрипт выполняет поиск каталогов по пути. При необходимости можно изменить строку SEARCH_PATH= для поиска других мест.

# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
    SEARCH_PATH=$PATH  # or any colon-delimited list of paths
    IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
    echo "##[debug] Found directories"
    for element in "${PathDirs[@]}"; do
        echo "$element"
    done;
    echo;
    echo;  
    echo "##[debug] Found files"
    for element in "${PathDirs[@]}"; do
        find "$element" -type f
    done

# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
    $SEARCH_PATH=$Env:Path
    Write-Host "##[debug] Found directories"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Write-Host "$Dir"
    }
    Write-Host ""
    Write-Host ""
    Write-Host "##[debug] Found files"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
        Write-Host $_.FullName
      }
    }

Различия между локальной командной строкой и агентом

Помните, что есть различия в действии при выполнении команды на локальном компьютере и при запуске сборки или релиза на агенте. Если агент настроен для запуска в качестве службы в Linux, macOS или Windows, он не выполняется в интерактивной сессии с активным пользователем. Без интерактивного сеанса входа в систему существуют ограничения, такие как невозможность взаимодействия с пользовательским интерфейсом.

Ошибки использования файла или папки

File or folder in use Ошибки указываются сообщениями об ошибках, такими как:

  • Access to the path [...] is denied.
  • The process cannot access the file [...] because it is being used by another process.
  • Access is denied.
  • Can't move [...] to [...]

Действия по устранению проблемы

Обнаружение используемых файлов и папок

В Windows такие инструменты, как Process Monitor, можно использовать для захвата трассировки событий файлов в определенном каталоге. Или для снимка состояния в данный момент можно использовать такие инструменты, как Process Explorer или Handle.

Исключение антивирусной защиты

Антивирусное программное обеспечение, проверяющее файлы, может привести к ошибкам использования файлов или папок во время сборки или выпуска. Добавление исключения антивирусной защиты для каталога агента и настроенной рабочей папки может помочь определить антивирусное программное обеспечение в качестве процесса вмешательства.

MSBuild и /nodeReuse:false

При вызове MSBuild во время сборки обязательно передайте аргумент /nodeReuse:false (короткая форма /nr:false). В противном случае процессы MSBuild продолжают выполняться после завершения сборки. Процессы остаются в течение некоторого времени в ожидании потенциальной последующей сборки.

Эта функция MSBuild может препятствовать попыткам удаления или перемещения каталога из-за конфликта с рабочим каталогом процессов MSBuild.

Задачи сборки MSBuild и Visual Studio уже добавляют /nr:false в аргументы, передаваемые в MSBuild. Однако при вызове MSBuild из собственного скрипта необходимо указать аргумент.

MSBuild и /maxcpucount:[n]

По умолчанию задачи сборки, такие как MSBuild и Visual Studio Build, запускают MSBuild с переключателем /m. В некоторых случаях это может вызвать такие проблемы, как несколько проблем с доступом к файлам процесса.

Попробуйте добавить аргумент /m:1 в задачи сборки, чтобы заставить MSBuild выполнять только один процесс за раз.

Проблемы с использованием файлов могут возникнуть при использовании функции параллельного процесса MSBuild. Неуказание аргумента /maxcpucount:[n] (короткая форма /m:[n]) приводит к тому, что MSBuild использует только один процесс. Если вы используете задачи сборки MSBuild или Visual Studio, может потребоваться указать "/m:1", чтобы переопределить аргумент "/m", добавленный по умолчанию.

Периодические или несогласованные сбои MSBuild

Если возникают периодические или несогласованные сбои MSBuild, попробуйте указать MSBuild использовать только один процесс. Периодические или несогласованные ошибки могут указывать на то, что целевая конфигурация несовместима с функцией параллельного процесса MSBuild. См. MSBuild и /maxcpucount:[n].

Процесс зависает

Процесс перестает отвечать на причины и действия по устранению неполадок:

Ожидание входных данных

Процесс, который перестает отвечать, может указывать на то, что процесс ожидает входных данных.

Запуск агента из командной строки интерактивного входа в сеанс может помочь определить, сопровождается ли процесс диалоговым окном ввода.

Запуск агента в качестве службы может помочь исключить запросы программ на ввод данных. Например, в .NET программы могут полагаться на логическое значение System.Environment.UserInteractive, чтобы определить, следует ли выполнять запрос. Если агент работает в качестве службы Windows, значение равно false.

Дамп обработки

Анализ дампа процесса может помочь определить, чего ожидает процесс, находящийся в состоянии взаимоблокировки.

Проект WiX

Создание проекта WiX при включении пользовательских средств ведения журнала MSBuild может привести к взаимоблокировке WiX, когда он ожидает завершения вывода в поток. Добавление дополнительного аргумента /p:RunWixToolsOutOfProc=true MSBuild обходит проблему.

Окончания строк для нескольких платформ

При запуске потоков на разных платформах иногда возникают проблемы с различными окончаниями строк. Исторически Linux и macOS использовали символы перевода строки (LF), в то время как Windows использовала возврат каретки и перевод строки (CRLF). Git пытается компенсировать разницу, автоматически завершая строки в репозитории символами LF, а в рабочем каталоге на Windows — символами CRLF.

Большинство инструментов Windows нормально работают с окончаниями только LF, и такое автоматическое поведение может вызвать больше проблем, чем решить их. Если вы сталкиваетесь с проблемами из-за концов строк, мы рекомендуем настроить Git, чтобы везде предпочитать LF. Для этого добавьте файл .gitattributes в корневой каталог репозитория. В этом файле добавьте следующую строку:

* text eol=lf

Переменные с добавлением одинарной кавычки

Если конвейер содержит скрипт Bash, который задает переменные с помощью ##vso команды, может появиться еще один ' добавленный к значению заданной переменной. Это происходит из-за взаимодействия с set -x. Решение заключается в временном отключении set -x перед настройкой переменной. Синтаксис Bash для этого — set +x.

set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x

Почему это происходит?

Многие скрипты Bash включают команду set -x для поддержки отладки. Bash отслеживает выполнение каждой команды и выводит её в stdout. Это приводит к тому, что агент дважды увидит ##vso команду, а второй раз Bash добавит ' символ в конец.

Например, рассмотрим этот конвейер:

steps:
- bash: |
    set -x
    echo ##vso[task.setvariable variable=MY_VAR]my_value

В stdout агент видит две строки:

##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'

Когда агент увидит первую строку, MY_VAR будет установлено на правильное значение "my_value". Однако, когда он видит вторую строку, агент обрабатывает все до конца строки. MY_VAR имеет значение "my_value'".

Библиотеки не устанавливаются для приложения Python при выполнении скрипта

При развертывании приложения Python в некоторых случаях конвейер CI/CD выполняется и код развертывается успешно, но файл requirements.txt , отвечающий за установку всех библиотек зависимостей, не выполняется.

Чтобы установить зависимости, используйте скрипт после развертывания в задаче развертывания службы приложений. В следующем примере показана команда, используемая в скрипте после развертывания. Скрипт можно обновить для вашего сценария.

D:\home\python364x64\python.exe -m pip install -r requirements.txt

Сведения об устранении неполадок, связанных с подключениями к службам, см. в разделе "Устранение неполадок с подключением службы". Чтобы специально устранить неполадки подключений служб с использованием удостоверения рабочей нагрузки для аутентификации, см. статью «Устранение неполадок подключений службы с удостоверением рабочей нагрузки».

Пайплайн перестал получать данные от агента

Если конвейер завершается ошибкой с сообщением, например, We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection., проверьте использование ресурсов агента, чтобы узнать, не заканчиваются ли ресурсы у компьютера агента. Начиная с Sprint 228журналы Azure Pipelines содержат метрики использования ресурсов для каждого шага.

При использовании Azure DevOps Services можно просмотреть использование ресурсов в журналах, включая использование дисков, памяти и ЦП, включив подробные журналы. По завершении конвейера выполните поиск по журналам записейAgent environment resources для каждого шага.

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

Сведения о сборе дополнительных журналов использования ресурсов см. в разделе "Сбор сведений об использовании ресурсов".

Активировать Storage Explorer для развертывания статического содержимого, такого как .css и .js, на статический веб-сайт через Azure Pipelines из Azure DevOps.

В этом сценарии можно использовать задачу копирования файлов Azure для загрузки содержимого на веб-сайт. Вы можете использовать любой из инструментов, описанных в разделе "Отправка содержимого " для отправки содержимого в веб-контейнер.

Дальнейшие действия