Создание репозиториев GitHub

Azure DevOps Services

Azure Pipelines может автоматически создавать и проверять каждый запрос на вытягивание и фиксировать его в репозитории GitHub. В этой статье описывается настройка интеграции между GitHub и Azure Pipelines.

Если вы не знакомы с интеграцией конвейеров с GitHub, выполните действия, описанные в разделе "Создание первого конвейера". Вернитесь к этой статье, чтобы узнать больше о настройке и настройке интеграции между GitHub и Azure Pipelines.

Организации и пользователи

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

Организации

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

Структура Azure DevOps состоит из организаций , содержащих проекты. См. раздел " Планирование структуры организации".

Azure DevOps может отражать структуру GitHub с помощью:

• Организация DevOps для вашей организации или учетной записи пользователя GitHub
• DevOps Projects для репозиториев GitHub

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

1. Создайте организацию DevOps с именем вашей организации или учетной записи пользователя GitHub. У него будет ТАКОЙ URL-адрес https://dev.azure.com/your-organization.
2. В организации DevOps создайте проекты с именем репозиториев. У них будут ТАКИЕ URL-адреса https://dev.azure.com/your-organization/your-repository.
3. В проекте DevOps создайте конвейеры с именем организации и репозитория GitHub, например your-organization.your-repository. Тогда ясно, какие репозитории они для.

После этого шаблона репозитории GitHub и Azure DevOps Projects будут иметь соответствующие URL-пути. Например:

Service	URL
GitHub	https://github.com/python/cpython
Azure DevOps	https://dev.azure.com/python/cpython

Пользователи

Пользователи GitHub не получают автоматический доступ к Azure Pipelines. Azure Pipelines не знает о удостоверениях GitHub. По этой причине невозможно настроить Azure Pipelines для автоматического уведомления пользователей о сбое сборки или сбое проверки pr с помощью удостоверения GitHub и адреса электронной почты. Необходимо явно создать новых пользователей в Azure Pipelines для репликации пользователей GitHub. После создания новых пользователей вы можете настроить свои разрешения в Azure DevOps, чтобы отразить их разрешения в GitHub. Вы также можете настроить уведомления в DevOps с помощью удостоверения DevOps.

Роли организации GitHub

Роли членов организации GitHub находятся по адресу https://github.com/orgs/your-organization/people (замените your-organization).

Разрешения участников организации DevOps найдены по https://dev.azure.com/your-organization/_settings/security адресу (замените your-organization).

Роли в организации GitHub и эквивалентных ролях в организации Azure DevOps показаны ниже.

Роль организации GitHub	Эквивалент организации DevOps
Ответственный	Член Project Collection Administrators
Менеджер по выставлению счетов	Член Project Collection Administrators
Элемент	Project Collection Valid UsersЧлен . По умолчанию группа участников не имеет разрешения на создание новых проектов. Чтобы изменить разрешение, задайте разрешение Allowгруппы Create new projects или создайте новую группу с нужными разрешениями.

Роли учетной записи пользователя GitHub

Учетная запись пользователя GitHub имеет одну роль, которая принадлежит учетной записи.

Разрешения участников организации DevOps найдены по https://dev.azure.com/your-organization/_settings/security адресу (замените your-organization).

Роль учетной записи пользователя GitHub сопоставляется с разрешениями организации DevOps, как показано ниже.

Роль учетной записи пользователя GitHub	Эквивалент организации DevOps
Ответственный	Член Project Collection Administrators

Разрешения репозитория GitHub

Разрешения репозитория GitHub находятся по https://github.com/your-organization/your-repository/settings/collaboration адресу (замена your-organization и your-repository).

Разрешения проекта DevOps находятся по https://dev.azure.com/your-organization/your-project/_settings/security адресу (замена your-organization и your-project).

Эквивалентные разрешения между репозиториями GitHub и Azure DevOps Projects приведены следующим образом.

Разрешение репозитория GitHub	Эквивалент проекта DevOps
Административный	Член Project Administrators
Write	Член Contributors
Читать	Член Readers

Если репозиторий GitHub предоставляет разрешения командам, вы можете создать соответствующие команды в Teams разделе параметров проекта Azure DevOps. Затем добавьте команды в группы безопасности выше, как и пользователи.

Разрешения для конкретного конвейера

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

1. Посетите страницу конвейеров проекта (например, https://dev.azure.com/your-organization/your-project/_build).
2. Выберите конвейер, для которого необходимо задать определенные разрешения.
3. В контекстном меню "..." выберите "Безопасность".
4. Нажмите кнопку "Добавить... ", чтобы добавить определенного пользователя, команду или группу и настроить их разрешения для конвейера.

Доступ к репозиториям GitHub

YAML

Создайте новый конвейер, сначала выбрав репозиторий GitHub, а затем файл YAML в этом репозитории. Репозиторий, в котором присутствует ФАЙЛ YAML, называется self репозиторием. По умолчанию это репозиторий, который выполняет сборки конвейера.

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

Классическое

Создайте новый конвейер, сначала выбрав GitHub для типа репозитория, а затем один из репозиториев, к которым у вас есть доступ.

Azure Pipelines необходимо предоставить доступ к репозиториям для активации своих сборок и получения кода во время сборки.

Существует три типа проверки подлинности для предоставления Azure Pipelines доступа к репозиториям GitHub при создании конвейера.

Тип аутентификации	Запуск конвейеров с помощью	Работает с проверками GitHub
1. Приложение GitHub	Удостоверение Azure Pipelines	Да
2. OAuth	Ваше личное удостоверение GitHub	No
3. Личный маркер доступа (PAT)	Ваше личное удостоверение GitHub	No

Проверка подлинности приложения GitHub

Приложение Azure Pipelines GitHub — это рекомендуемый тип проверки подлинности для конвейеров непрерывной интеграции. После установки приложения GitHub в учетной записи или организации GitHub конвейер будет работать без использования личного удостоверения GitHub. Сборки и обновления состояния GitHub будут выполняться с помощью удостоверения Azure Pipelines. Приложение работает с GitHub Checks для отображения результатов сборки, тестирования и покрытия кода в GitHub.

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

После установки приложение GitHub станет методом проверки подлинности Azure Pipelines по умолчанию для GitHub (вместо OAuth), когда конвейеры создаются для репозиториев.

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

Разрешения, необходимые в GitHub

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

• Если репозиторий находится в вашей личной учетной записи GitHub, установите приложение Azure Pipelines GitHub в личной учетной записи GitHub, и вы сможете перечислить этот репозиторий при создании конвейера в Azure Pipelines.

• Если репозиторий находится в личной учетной записи GitHub другого пользователя, другой пользователь должен установить приложение Azure Pipelines GitHub в своей личной учетной записи GitHub. Необходимо добавить в качестве участника совместной работы в параметрах репозитория в разделе "Сотрудники". Примите приглашение для совместной работы с помощью ссылки, отправленной вам по электронной почте. После этого можно создать конвейер для этого репозитория.

• Если репозиторий находится в организации GitHub, которую вы владеете, установите приложение Azure Pipelines GitHub в организации GitHub. Вы также должны быть добавлены в качестве участника совместной работы или ваша команда должна быть добавлена в параметры репозитория в разделе "Сотрудники и команды".

• Если репозиторий находится в организации GitHub, принадлежащей другому пользователю, администратор GitHub владелец организации или репозитория должен установить приложение Azure Pipelines GitHub в организации. Необходимо добавить в качестве участника совместной работы или добавить команду в параметры репозитория в разделе "Сотрудники и команды". Примите приглашение для совместной работы с помощью ссылки, отправленной вам по электронной почте.

Разрешения приложения GitHub

Приложение GitHub запрашивает следующие разрешения во время установки:

Разрешение	Как Azure Pipelines использует разрешение
Доступ для записи к коду	Только после преднамеренного действия Azure Pipelines упрощает создание конвейера, зафиксировав YAML-файл в выбранную ветвь репозитория GitHub.
Доступ для чтения к метаданным	Azure Pipelines извлекает метаданные GitHub для отображения репозитория, ветвей и проблем, связанных со сборкой в сводке сборки.
Доступ на чтение и запись для проверок	Azure Pipelines считывает и записывает собственные результаты сборки, тестирования и покрытия кода, которые будут отображаться в GitHub.
Доступ на чтение и запись для запросов на вытягивание	Только после преднамеренного действия Azure Pipelines упрощает создание конвейера путем создания запроса на вытягивание для YAML-файла, который был зафиксирован в выбранной ветви репозитория GitHub. Конвейеры извлекают метаданные запроса для отображения в сводках сборки, связанных с запросами на вытягивание.

Устранение неполадок при установке приложения GitHub

GitHub может отобразить ошибку, например:

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

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

Создание конвейеров в нескольких организациях и проектах Azure DevOps

После установки приложения GitHub конвейеры можно создать для репозиториев организации в разных организациях и проектах DevOps. Однако при создании конвейеров для одного репозитория в нескольких организациях Azure DevOps можно автоматически активировать только конвейеры первой организации с помощью фиксаций GitHub или запросов на вытягивание. Сборки вручную или запланированные сборки по-прежнему возможны в вторичных организациях Azure DevOps.

Аутентификация OAuth

OAuth — это самый простой тип проверки подлинности для начала работы с репозиториями в личной учетной записи GitHub. Обновления состояния GitHub будут выполняться от имени личного удостоверения GitHub. Чтобы конвейеры работали, доступ к репозиторию должен оставаться активным. Некоторые функции GitHub, такие как проверки, недоступны в OAuth и требуют приложения GitHub.

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

Разрешения, необходимые в GitHub

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

• Если репозиторий находится в вашей личной учетной записи GitHub, по крайней мере один раз, выполните проверку подлинности в GitHub с помощью OAuth с помощью личных учетных данных учетной записи GitHub. Это можно сделать в параметрах проекта Azure DevOps в разделе "Подключения службы конвейеров>" для GitHub > New service connection>.> Предоставьте Azure Pipelines доступ к репозиториям в разделе "Разрешения".

• Если репозиторий находится в личной учетной записи GitHub другого пользователя, по крайней мере один раз другой пользователь должен пройти проверку подлинности в GitHub с помощью OAuth, используя учетные данные своей личной учетной записи GitHub. Это можно сделать в параметрах проекта Azure DevOps в разделе "Подключения службы конвейеров>" для GitHub > New service connection>.> Другой пользователь должен предоставить Azure Pipelines доступ к репозиториям в разделе "Разрешения". Необходимо добавить в качестве участника совместной работы в параметрах репозитория в разделе "Сотрудники". Примите приглашение для совместной работы с помощью ссылки, отправленной вам по электронной почте.

• Если репозиторий находится в организации GitHub, которую вы владеете, по крайней мере один раз, выполните проверку подлинности в GitHub с помощью OAuth с помощью личных учетных данных учетной записи GitHub. Это можно сделать в параметрах проекта Azure DevOps в разделе "Подключения службы конвейеров>" для GitHub > New service connection>.> Предоставьте azure Pipelines доступ к вашей организации в разделе "Доступ к организации". Необходимо добавить в качестве участника совместной работы или добавить команду в параметры репозитория в разделе "Сотрудники и команды".

• Если репозиторий находится в организации GitHub, которая принадлежит другому пользователю, по крайней мере один раз, GitHub владелец организации должна пройти проверку подлинности в GitHub с помощью OAuth с помощью учетных данных учетной записи GitHub. Это можно сделать в параметрах проекта Azure DevOps в разделе "Подключения службы конвейеров>" для GitHub > New service connection>.> Владелец организации должен предоставить Azure Pipelines доступ к организации в разделе "Доступ к организации". Необходимо добавить в качестве участника совместной работы или добавить команду в параметры репозитория в разделе "Сотрудники и команды". Примите приглашение для совместной работы с помощью ссылки, отправленной вам по электронной почте.

Отзыв доступа OAuth

После авторизации Azure Pipelines использовать OAuth, чтобы отменить его и предотвратить дальнейшее использование, посетите Приложение OAuth в параметрах GitHub. Вы также можете удалить его из списка подключений службы GitHub в параметрах проекта Azure DevOps.

Проверка подлинности личного маркера доступа (PAT)

PaTs фактически совпадают с OAuth, но позволяют контролировать, какие разрешения предоставляются Azure Pipelines. Сборки и обновления состояния GitHub будут выполняться от имени личного удостоверения GitHub. Для поддержания работы сборок доступ к репозиторию должен оставаться активным.

Чтобы создать PAT, посетите личные маркеры доступа в параметрах GitHub. Необходимые разрешения: repo, admin:repo_hookread:userи user:email. Это те же разрешения, необходимые при использовании OAuth выше. Скопируйте созданный PAT в буфер обмена и вставьте его в новое подключение службы GitHub в параметрах проекта Azure DevOps. Для дальнейшего отзыва назовите подключение службы после имени пользователя GitHub. Он будет доступен в проекте Azure DevOps для последующего использования при создании конвейеров.

Разрешения, необходимые в GitHub

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

• Если репозиторий находится в вашей личной учетной записи GitHub, ПАТ должен иметь необходимые области доступа в рамках личных маркеров доступа: repo, admin:repo_hookи read:useruser:email.

• Если репозиторий находится в личной учетной записи GitHub другого пользователя, ПАТ должен иметь необходимые области доступа в рамках личных маркеров доступа: repo, admin:repo_hookи read:useruser:email. Необходимо добавить в качестве участника совместной работы в параметрах репозитория в разделе "Сотрудники". Примите приглашение для совместной работы с помощью ссылки, отправленной вам по электронной почте.

• Если репозиторий находится в организации GitHub, у него должны быть необходимые области доступа в личных маркерах доступа: repo, admin:repo_hookи read:useruser:email. Необходимо добавить в качестве участника совместной работы или добавить команду в параметры репозитория в разделе "Сотрудники и команды".

• Если репозиторий находится в организации GitHub, принадлежащей другому пользователю, ПАТ должен иметь необходимые области доступа в соответствии с личными маркерами доступа: repo, read:useradmin:repo_hookи user:email. Необходимо добавить в качестве участника совместной работы или добавить команду в параметры репозитория в разделе "Сотрудники и команды". Примите приглашение для совместной работы с помощью ссылки, отправленной вам по электронной почте.

Отзыв доступа PAT

После авторизации Azure Pipelines использовать PAT, чтобы позже удалить его и предотвратить дальнейшее использование, посетите личные маркеры доступа в параметрах GitHub. Вы также можете удалить его из списка подключений службы GitHub в параметрах проекта Azure DevOps.

Триггеры CI

Триггеры непрерывной интеграции (CI) вызывают запуск конвейера при отправке обновления в указанные ветви или при отправке указанных тегов.

YAML

Конвейеры YAML настраиваются по умолчанию с триггером CI во всех ветвях, если не включен параметр триггера YAML CI, представленный в спринте Azure DevOps 227. Параметр триггера CI disable отключается на уровне организации или на уровне проекта. Если включен параметр триггера CI отключать подразумеваемый параметр YAML, триггеры CI для конвейеров YAML не включены, если конвейер YAML не содержит trigger раздел. По умолчанию отключена подразумеваемая активация CI YAML.

Ветви

Вы можете контролировать, какие ветви получают триггеры CI с помощью простого синтаксиса:

trigger:
- main
- releases/*

Можно указать полное имя ветви (например, main) или подстановочный знак (например, releases/*). Сведения о синтаксисе подстановочных знаков см . в подстановочных знаках .

Примечание.

Переменные нельзя использовать в триггерах, так как переменные оцениваются во время выполнения (после запуска триггера).

Примечание.

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

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

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

В приведенном выше примере конвейер будет активирован, если изменение отправляется в main или в любую ветвь выпусков. Тем не менее, он не будет активирован, если изменения внесены в ветвь выпусков, которая начинается с old.

Если указать exclude предложение без include предложения, это эквивалентно указанию * в предложении include .

Помимо указания имен ветвей в branches списках, можно также настроить триггеры на основе тегов с помощью следующего формата:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Если вы не указали какие-либо триггеры, а параметр триггера YAML CI disable не включен, по умолчанию используется значение по умолчанию, как если бы вы написали:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Внимание

При указании триггера он заменяет неявный триггер по умолчанию и отправляет только в ветви, которые явно настроены для включения, активируют конвейер. Сначала обрабатываются компоненты, а затем исключения удаляются из этого списка.

Запуски CI пакетной обработки

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

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

Примечание.

batch не поддерживается в триггерах ресурсов репозитория.

Чтобы прояснить этот пример, предположим, что принудительное A main выполнение приведенного выше конвейера привело к выполнению. При выполнении этого конвейера в репозиторий выполняются дополнительные push-передачи B и C возникают. Эти обновления не запускают новые независимые запуски немедленно. Но после завершения первого запуска все отправки до тех пор, пока этот момент времени не будет пакетирован и запущен новый запуск.

Примечание.

Если конвейер имеет несколько заданий и этапов, первый запуск по-прежнему должен достичь состояния терминала, завершив или пропуская все его задания и этапы до начала второго запуска. По этой причине необходимо соблюдать осторожность при использовании этой функции в конвейере с несколькими этапами или утверждениями. Если вы хотите пакетировать сборки в таких случаях, рекомендуется разделить процесс CI/CD на два конвейера— один для сборки (с пакетной обработкой) и один для развертываний.

Пути

Можно указать пути к файлам для включения или исключения.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

При указании путей необходимо явно указать ветви для активации при использовании Azure DevOps Server 2019.1 или более поздней версии. Невозможно активировать конвейер только с фильтром пути; Необходимо также иметь фильтр ветви, а измененные файлы, соответствующие фильтру пути, должны быть из ветви, которая соответствует фильтру ветви. Если вы используете Azure DevOps Server 2020 или более поздней версии, можно пропустить branches фильтрацию по всем ветвям в сочетании с фильтром пути.

Подстановочные карточки поддерживаются для фильтров путей. Например, можно включить все пути, соответствующие src/app/**/myapp*. Можно использовать подстановочные знаки (**или *?) при указании фильтров путей).

• Пути всегда указываются относительно корневого каталога репозитория.
• Если фильтры путей не заданы, корневая папка репозитория неявно включена по умолчанию.
• Если вы исключите путь, вы также не можете включить его, если вы не квалифицируйте его в более глубокую папку. Например, если вы исключите /tools , можно включить /tools/trigger-runs-on-on-these
• Порядок фильтров путей не имеет значения.
• Пути в Git чувствительны к регистру. Обязательно используйте тот же случай, что и реальные папки.
• Переменные нельзя использовать в путях, так как переменные оцениваются во время выполнения (после запуска триггера).

Теги

Помимо указания тегов в списках, описанных в branches предыдущем разделе, можно напрямую указать теги для включения или исключения:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

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

Внимание

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

Отказ от CI

Отключение триггера CI

Вы можете полностью отказаться от триггеров CI, указав trigger: none.

# A pipeline with no CI trigger
trigger: none

Внимание

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

Классическое

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

Пакетные изменения

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

Вы можете пакетные изменения и создать их вместе.

Примечание.

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

• Не используйте пакетную обработку
• разделение конвейера на два отдельных конвейера — один для CI и одного CD
• задайте соответствующие условия на этапах, чтобы пропустить их и быстро завершить выполнение

Фильтры ветвей

Можно указать ветви, в которых требуется активировать сборки. Если вы хотите использовать подстановочные знаки, введите спецификацию ветви (например, features/modules/*) и нажмите клавишу ВВОД.

Фильтры путей

Если репозиторий Git находится в Azure Repos или TFS, можно также указать фильтры путей, чтобы уменьшить набор файлов, которые требуется активировать сборку.

Совет.

• Пути всегда указываются относительно корневого каталога репозитория.
• Если фильтры путей не заданы, корневая папка репозитория неявно включена по умолчанию.
• Если вы исключите путь, вы также не можете включить его, если вы не квалифицируйте его в более глубокую папку. Например, если вы исключите /tools , можно включить /tools/trigger-runs-on-on-these
• Порядок фильтров путей не имеет значения.
• Пути в Git чувствительны к регистру. Обязательно используйте тот же случай, что и реальные папки.

Пример

Например, вы хотите, чтобы сборка была активирована изменениями main и большинством, но не всеми ветвь компонента. Вы также не хотите, чтобы сборки активировались изменениями файлов в папке инструментов.

Пропуск CI для отдельных фиксаций

Вы также можете сообщить Azure Pipelines пропустить запуск конвейера, что push-отправка обычно активируется. Просто включите [skip ci] в сообщение или описание любого из фиксаций, которые являются частью принудительной отправки, и Azure Pipelines пропустит выполнение CI для этой отправки. Вы также можете использовать любой из следующих вариантов.

• [skip ci] или [ci skip]
• skip-checks: true или skip-checks:true
• [skip azurepipelines] или [azurepipelines skip]
• [skip azpipelines] или [azpipelines skip]
• [skip azp] или [azp skip]
• ***NO_CI***

Использование типа триггера в условиях

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

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Поведение триггеров при создании новых ветвей

Обычно для одного репозитория настраивается несколько конвейеров. Например, у вас может быть один конвейер для создания документов для приложения и другого для создания исходного кода. Триггеры CI можно настроить с соответствующими фильтрами ветвей и фильтрами путей в каждом из этих конвейеров. Например, может потребоваться, чтобы один конвейер активировался при отправке обновления в docs папку, а другой — при отправке обновления в код приложения. В этих случаях необходимо понять, как конвейеры активируются при создании новой ветви.

Ниже приведено поведение при отправке новой ветви (которая соответствует фильтрам ветвей) в репозиторий:

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

Подстановочные знаки

При указании ветви, тега или пути можно использовать точное имя или подстановочный знак. Подстановочные знаки позволяют * соответствовать нулю или нескольким символам и ? соответствовать одному символу.

• Если вы начинаете шаблон с * конвейера YAML, необходимо упаковать шаблон в кавычки, например "*-releases".
• Для ветвей и тегов:
  • Подстановочный знак может отображаться в любом месте шаблона.
• Для путей:
  • В Azure DevOps Server 2022 и более поздних версиях, включая Azure DevOps Services, подстановочный знак может отображаться в любом месте в шаблоне пути, и вы можете использовать * или ?.
  • В Azure DevOps Server 2020 и более низких можно включить * в качестве окончательного символа, но он не делает ничего другого от указания имени каталога самостоятельно. Вы не можете включить * в середину фильтра пути, и вы не можете использовать?.

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Триггеры PR

Триггеры запроса на вытягивание (PR) вызывают выполнение конвейера при открытии запроса на вытягивание с одной из указанных целевых ветвей или при обновлении такого запроса на вытягивание.

YAML

Ветви

Вы можете указать целевые ветви при проверке запросов на вытягивание. Например, чтобы проверить запросы на вытягивание, предназначенные для этого объекта main , releases/*можно использовать следующий pr триггер.

pr:
- main
- releases/*

Эта конфигурация запускает новый запуск при первом создании нового запроса на вытягивание и после каждого обновления, сделанного в запрос на вытягивание.

Можно указать полное имя ветви (например, main) или подстановочный знак (например, releases/*).

Примечание.

Переменные нельзя использовать в триггерах, так как переменные оцениваются во время выполнения (после запуска триггера).

Примечание.

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

GitHub создает ссылку при создании запроса на вытягивание. Ссылка указывает на фиксацию слияния, которая представляет собой объединенный код между исходными и целевыми ветвями запроса на вытягивание. Конвейер проверки pr создает фиксацию, к которому указывает этот ссылочный объект. Это означает, что файл YAML, используемый для запуска конвейера, также является слиянием между источником и целевой ветвью. В результате изменения, внесенные в ФАЙЛ YAML в исходной ветви запроса на вытягивание, могут переопределить поведение, определенное файлом YAML в целевой ветви.

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

pr:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Внимание

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

Для более сложных триггеров, которые должны исключить определенные ветви, необходимо использовать полный синтаксис, как показано в следующем примере. В этом примере запросы на вытягивание проверяются, что целевой объект main или releases/* ветвь releases/old* исключены.

# specific branch
pr:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

Пути

Можно указать пути к файлам для включения или исключения. Например:

# specific path
pr:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Совет.

• Azure Pipelines отправляет нейтральное состояние обратно в GitHub, когда он решает не запускать сборку проверки из-за правила исключения пути. Это обеспечивает четкое направление на GitHub, указывающее, что Azure Pipelines завершила обработку. Дополнительные сведения см. в статье "Запись нейтрального состояния" в GitHub при пропуске сборки.
• Подстановочные карточки теперь поддерживаются с фильтрами путей.
• Пути всегда указываются относительно корневого каталога репозитория.
• Если фильтры путей не заданы, корневая папка репозитория неявно включена по умолчанию.
• Если вы исключите путь, вы также не можете включить его, если вы не квалифицируйте его в более глубокую папку. Например, если вы исключите /tools , можно включить /tools/trigger-runs-on-on-these
• Порядок фильтров путей не имеет значения.
• Пути в Git чувствительны к регистру. Обязательно используйте тот же случай, что и реальные папки.
• Переменные нельзя использовать в путях, так как переменные оцениваются во время выполнения (после запуска триггера).
• Azure Pipelines отправляет нейтральное состояние обратно в GitHub, когда он решает не запускать сборку проверки из-за правила исключения пути.

Несколько обновлений pr

Можно указать, следует ли указать, следует ли отменять запуски проверки во время выполнения проверки для одного и того же pr. Значение по умолчанию — true.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

Проверка черновика pr

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

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

Отказ от проверки pr

Вы можете полностью отказаться от проверки запроса на вытягивание, указав pr: none.

# no PR triggers
pr: none

Дополнительные сведения см. в разделе "Триггер pr" в схеме YAML.

Примечание.

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

Классическое

Выберите триггер проверки запроса на вытягивание и установите флажок "Включить проверку запроса на вытягивание", чтобы включить сборки на запросы на вытягивание.

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

Если у вас есть открытый PR и вы отправляете изменения в исходную ветвь, может выполняться несколько конвейеров:

• Конвейеры с триггером pr в целевой ветви PR будут выполняться в фиксации слияния (объединенный код между исходным и целевым ветвями запроса на вытягивание), независимо от того, существуют ли отправленные фиксации, сообщения или описания которых содержат [skip ci] (или любой из его вариантов).
• Конвейеры, активированные изменениями в исходной ветви PR, если нет push-фиксаций, сообщения или описания которых содержат [skip ci] (или любой из его вариантов). Если по крайней мере одна отправленная фиксация содержит [skip ci], конвейеры не будут выполняться.

Наконец, после слияния pr Azure Pipelines будет запускать конвейеры CI, инициируемые отправкой в целевую ветвь, если сообщение или описание фиксации слияния не содержит [skip ci] (или какие-либо из его вариантов).

Защищенные ветви

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

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

1. Сначала создайте конвейер для репозитория и создайте его по крайней мере один раз, чтобы его состояние было размещено в GitHub, тем самым учитывая имя конвейера.

2. Затем следуйте документации GitHub по настройке защищенная ветвь в параметрах репозитория.

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

   

Внимание

Если конвейер не отображается в этом списке, убедитесь в следующем:

• Вы используете проверку подлинности приложения GitHub
• Конвейер выполняется по крайней мере один раз за последнюю неделю

Вклад внешних источников

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

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

• Ограничения доступа
• Проверка вкладов из вилок
• Важные вопросы безопасности

Ограничения доступа

Помните о следующих ограничениях доступа при запуске конвейеров в общедоступных проектах Azure DevOps:

• Секреты. По умолчанию секреты, связанные с конвейером, недоступны для проверки запросов на вытягивание вилок. См. статью "Проверка вкладов из вилок".
• Доступ между проектами: все конвейеры в общедоступном проекте Azure DevOps выполняются с маркером доступа, ограниченным для проекта. Конвейеры в общедоступном проекте могут получить доступ к ресурсам, таким как артефакты сборки или тестовые результаты только в проекте, а не в других проектах организации Azure DevOps.
• Пакеты Артефактов Azure. Если конвейеры нуждаются в доступе к пакетам из Azure Artifacts, необходимо явно предоставить разрешение учетной записи службы сборки проекта для доступа к веб-каналам пакетов.

Вклады из вилок

Внимание

Эти параметры влияют на безопасность конвейера.

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

1. Перейдите в проект Azure DevOps. Выберите конвейеры, найдите конвейер и нажмите кнопку "Изменить".
2. Выберите вкладку "Триггеры". После включения триггера запроса на вытягивание включите или отключите запросы на извлечение сборки из вилок этого репозитория.

По умолчанию с конвейерами GitHub секреты, связанные с конвейером сборки, недоступны для сборок запросов на вытягивание вилок. Эти секреты включены по умолчанию с конвейерами GitHub Enterprise Server. Секреты включают в себя:

• Маркер безопасности с доступом к репозиторию GitHub.
• Эти элементы, если конвейер использует их:
  • Учетные данные подключения службы
  • Файлы из библиотеки защищенных файлов
  • Переменные сборки помечены секретом

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

Примечание.

Если включить сборки fork для доступа к секретам, Azure Pipelines по умолчанию ограничивает маркер доступа, используемый для сборок вилки. Он имеет более ограниченный доступ к открытым ресурсам, чем обычный маркер доступа. Чтобы предоставить вилкам те же разрешения, что и обычные сборки, включите сборки Make fork имеют те же разрешения, что и обычные параметры сборки .

Дополнительные сведения см. в разделе "Защита репозитория " Вилки".

Вы можете централизованно определить, как конвейеры создают PR из вилированных репозиториев GitHub, используя запросы на вытягивание из вилированных репозиториев GitHub. Он доступен на уровне организации и проекта. Можно выбрать:

• Отключение создания запросов на вытягивание из вилки репозиториев
• Безопасное создание запросов на извлечение из вилки репозиториев
• Настройка правил для создания запросов на вытягивание из вилки репозиториев

Начиная с Sprint 229, чтобы повысить безопасность конвейеров, Azure Pipelines больше не создает запросы на вытягивание из вилированных репозиториев GitHub. Для новых проектов и организаций значение по умолчанию для запросов на вытягивание из вилки репозиториев GitHub по умолчанию — отключить сборку запросов на вытягивание из вилированных репозиториев.

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

При выборе параметра "Настройка" можно определить, как ограничить параметры конвейера. Например, можно убедиться, что всем конвейерам требуется комментарий, чтобы создать pr из вилированного репозитория GitHub, если pr принадлежит членам не команды и не участнику. Но вы можете разрешить им сделать секреты доступными для таких сборок. Проекты могут не разрешать конвейерам создавать такие PR или безопасно создавать их или иметь еще более строгие параметры, чем указано на уровне организации.

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

Важные вопросы безопасности

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

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

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

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

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

Триггеры комментариев

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

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

Чтобы включить триггеры комментариев, необходимо выполнить следующие два шага:

1. Включите триггеры запроса на вытягивание для конвейера и убедитесь, что вы не исключили целевую ветвь.
2. На веб-портале Azure Pipelines измените конвейер и выберите другие действия, триггеры. Затем в разделе проверки запроса на вытягивание включите комментарий участника команды перед созданием запроса на вытягивание.
   • Выберите "По всем запросам на вытягивание", чтобы требовать комментарий участника группы перед созданием запроса на вытягивание. С помощью этого рабочего процесса член группы проверяет запрос на вытягивание и запускает сборку с комментарием после того, как запрос на вытягивание считается безопасным.
   • Выберите только запросы на вытягивание от участников, не являющихся участниками команды, чтобы требовать комментарий участника команды только в том случае, если участник группы не является участником команды. В этом рабочем процессе участник команды не нуждается в проверке участника вторичной команды для активации сборки.

С этими двумя изменениями сборка проверки запроса на вытягивание не будет активирована автоматически, если только при выборе запроса на вытягивание от участников команды, а pr выполняется членом группы. Только владельцы репозитория и сотрудники с разрешением "Запись" могут активировать сборку, закомментировав запрос на вытягивание или /AzurePipelines run /AzurePipelines run <pipeline-name>.

Следующие команды можно вывести в Azure Pipelines в комментариях:

Команда	Результат
/AzurePipelines help	Отображение справки для всех поддерживаемых команд.
/AzurePipelines help <command-name>	Отображение справки для указанной команды.
/AzurePipelines run	Запустите все конвейеры, связанные с этим репозиторием, и триггеры которых не исключают этот запрос на вытягивание.
/AzurePipelines run <pipeline-name>	Запустите указанный конвейер, если его триггеры не исключают этот запрос на вытягивание.

Примечание.

Для краткости можно закомментировать, используя /azp вместо /AzurePipelinesэтого.

Внимание

Ответы на эти команды будут отображаться в обсуждении запроса на вытягивание только в том случае, если конвейер использует приложение GitHub Azure Pipelines.

Устранение неполадок триггеров примечания запроса на вытягивание

Если у вас есть необходимые разрешения репозитория, но конвейеры не активируются вашими комментариями, убедитесь, что членство является общедоступным в организации репозитория или непосредственно добавляете себя в качестве участника совместной работы репозитория. Конвейеры не могут видеть членов частной организации, если они не являются прямыми участниками совместной работы или не принадлежат к команде, которая является прямым сотрудником. Вы можете изменить членство в организации GitHub с частного на общедоступное здесь (замените Your-Organization его именем организации): https://github.com/orgs/Your-Organization/people

Информационные запуски

Информационное выполнение сообщает, что Azure DevOps не удалось получить исходный код конвейера YAML. Извлечение исходного кода происходит в ответ на внешние события, например, принудительно отправленную фиксацию. Это также происходит в ответ на внутренние триггеры, например, чтобы проверить наличие изменений кода и запустить запланированный запуск или нет. Получение исходного кода может завершиться сбоем по нескольким причинам, при этом часто запрашивается регулирование поставщиком репозитория Git. Существование информационного запуска не обязательно означает, что Azure DevOps собирается запустить конвейер.

Информационный запуск выглядит на следующем снимке экрана.

Вы можете распознать информационный запуск следующими атрибутами:

• Состояние Canceled
• Длительность составляет < 1s
• Имя выполнения содержит один из следующих текстов:
  • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
  • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
  • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
  • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
• Имя запуска обычно содержит ошибку BitBucket / GitHub, которая привела к сбою загрузки конвейера YAML
• Нет этапов/ заданий и шагов

Дополнительные сведения о информационных запусках.

Оформление

При активации конвейера Azure Pipelines извлекает исходный код из репозитория Azure Repos Git. Вы можете управлять различными аспектами того, как это происходит.

Примечание.

При включении шага выхода в конвейер мы выполните следующую команду: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1 Если это не соответствует вашим потребностям, можно исключить встроенный выход checkout: none , а затем использовать задачу скрипта для выполнения собственного заказа.

Предпочтительная версия Git

Агент Windows поставляется с собственной копией Git. Если вы предпочитаете предоставлять собственный Git, а не использовать включенную копию, задайте для trueнего значение System.PreferGitFromPath . Этот параметр всегда имеет значение true в агентах, отличных от Windows.

Путь к извлечению

YAML

Если вы извлекаете один репозиторий, по умолчанию исходный код будет извлечен в каталог с именем s. Для конвейеров YAML это можно изменить, указав checkout его.path Указанный путь относительно $(Agent.BuildDirectory). Например, если значение пути к извлечению и имеет значение mycustompath $(Agent.BuildDirectory) C:\agent\_work\1, исходный код будет извлечен в .C:\agent\_work\1\mycustompath

При использовании нескольких шагов и извлечении нескольких checkout репозиториев и явном указании папки, pathкаждый репозиторий помещается в вложенную папку s с именем в честь репозитория. Например, если вы извлекаете два репозитория с именем tools и code, исходный код будет извлечен в C:\agent\_work\1\s\tools и C:\agent\_work\1\s\code.

Обратите внимание, что значение пути к выходу не может быть задано на любом уровне каталога выше $(Agent.BuildDirectory), поэтому path\..\anotherpath приведет к допустимому пути извлечения (т C:\agent\_work\1\anotherpath. е.), но значение ..\invalidpath , например, не будет (т. е. C:\agent\_work\invalidpathне ).

Параметр можно настроить path на шаге выхода конвейера.

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

Классическое

Этот параметр не настраивается в классическом редакторе. Исходный код будет извлечен в каталог с именем s, который относится к $(Agent.BuildDirectory). Например, если $(Agent.BuildDirectory) есть C:\agent\_work\1, исходный код будет извлечен в C:\agent\_work\1\mycustompath.

Подмодулы

YAML

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

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

Классическое

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

Конвейер сборки будет проверять подмодулы Git до тех пор, пока они:

• Unauthenticated: общедоступный, не прошедший проверку подлинности репозиторий без учетных данных, необходимых для клонирования или получения.

• Проверкой подлинности:

  • Содержится в том же проекте, что и репозиторий Azure Repos Git, указанный выше. Те же учетные данные, которые используются агентом для получения источников из основного репозитория, также используются для получения источников для подмодул.

  • Добавлен URL-адрес относительно основного репозитория. Например.

    • Этот будет извлечен: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      В этом примере подмодул ссылается на репозиторий (FabrikamFiber) в той же организации Azure DevOps, но в другом проекте (FabrikamFiberProject). Те же учетные данные, которые используются агентом для получения источников из основного репозитория, также используются для получения источников для подмодул. Для этого требуется, чтобы маркер доступа к заданию получил доступ к репозиторию во втором проекте. Если маркер доступа к заданию ограничен, как описано в приведенном выше разделе, вы не сможете это сделать. Маркер доступа к заданию можно разрешить доступ к репозиторию во втором проекте путем явного предоставления доступа к учетной записи службы сборки проекта во втором проекте или (b) с помощью маркеров доступа с областью сбора, а не маркеров с областью проекта для всей организации. Дополнительные сведения об этих параметрах и их последствиях для безопасности см. в репозиториях Access, артефактах и других ресурсах.

    • Этот не будет извлечен: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Альтернатива использованию параметра подмодулы checkout

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

Если вы не можете использовать параметр подмодулы checkout, вместо этого можно использовать настраиваемый шаг скрипта для получения вложенных модулей. Сначала получите личный маркер доступа (PAT) и префикс его pat:. Затем в кодировке base64 эта префиксированная строка создается базовый маркер проверки подлинности. Наконец, добавьте этот скрипт в конвейер:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Обязательно замените "<BASE64_ENCODED_STRING>" строкой в кодировке Base64 "pat:token".

Используйте секретную переменную в проекте или конвейере сборки для хранения базового маркера проверки подлинности, созданного вами. Используйте ее для заполнения секрета в приведенной выше команде Git.

Примечание.

Вопрос. Почему я не могу использовать диспетчер учетных данных Git в агенте? A: Хранение учетных данных подмодула в диспетчере учетных данных Git, установленного в частном агенте сборки, обычно не действует, так как диспетчер учетных данных может повторно ввести учетные данные при обновлении подмодула. Это не желательно во время автоматизированных сборок, когда взаимодействие с пользователем невозможно.

Теги синхронизации

Внимание

Функция тегов синхронизации поддерживается в Azure Repos Git с Azure DevOps Server 2022.1 и выше.

Шаг извлечения использует --tags параметр при получении содержимого репозитория Git. Это приводит к тому, что сервер извлекает все теги, а также все объекты, на которые указывают эти теги. Это увеличивает время выполнения задачи в конвейере, особенно если у вас есть большой репозиторий с рядом тегов. Кроме того, шаг извлечения синхронизирует теги, даже если включить параметр мелкой выборки, тем самым, возможно, победить его назначение. Чтобы уменьшить объем данных, полученных или извлекаемых из репозитория Git, корпорация Майкрософт добавила новый параметр для контроля поведения синхронизации тегов. Этот параметр доступен как в классических, так и в конвейерах YAML.

Можно ли синхронизировать теги при извлечении репозитория в YAML, задав fetchTags свойство и в пользовательском интерфейсе, настроив параметр тегов синхронизации.

YAML

Параметр можно настроить fetchTags на шаге выхода конвейера.

Чтобы настроить параметр в YAML, задайте fetchTags свойство.

steps:
- checkout: self
  fetchTags: true

Этот параметр также можно настроить с помощью параметра тегов синхронизации в пользовательском интерфейсе параметров конвейера.

1. Измените конвейер YAML и выберите "Дополнительные действия", "Триггеры".

   

2. Выберите YAML, Get sources(Получить источники).

   

3. Настройте параметр тегов синхронизации.

   

Примечание.

Если этот параметр явно задан fetchTags на шаге, этот параметр имеет приоритет над параметром, настроенным в checkout пользовательском интерфейсе параметров конвейера.

Классическое

Вы можете настроить параметр тегов синхронизации из свойств задачи Get sources в конвейере.

Поведение по умолчанию

• Для существующих конвейеров, созданных до выпуска спринта Azure DevOps 209, выпущенного в сентябре 2022 года, значение по умолчанию для синхронизации тегов остается таким же, как и существующее поведение перед добавлением параметров тегов синхронизации.true
• Для новых конвейеров, созданных после выпуска спринта Azure DevOps 209, используется falseзначение по умолчанию для синхронизации тегов.

Примечание.

Если этот параметр явно задан fetchTags на шаге, этот параметр имеет приоритет над параметром, настроенным в checkout пользовательском интерфейсе параметров конвейера.

Неглубокое получение

Возможно, вы захотите ограничить, насколько далеко назад в истории, чтобы скачать. Фактически это приводит к тому, что это приведет к тому, что git fetch --depth=n Если репозиторий велик, этот параметр может повысить эффективность конвейера сборки. Ваш репозиторий может быть большим, если он используется в течение длительного времени и имеет большой журнал. Он также может быть большим, если вы добавили и позже удалили большие файлы.

Внимание

Новые конвейеры, созданные после обновления Azure DevOps за сентябрь 2022 г. спринтом 209 г., включают неглубокое получение по умолчанию и настроены с глубиной 1. Ранее значение по умолчанию не было мелким получением. Чтобы проверить конвейер, просмотрите параметр "Мелкое получение " в пользовательском интерфейсе параметров конвейера, как описано в следующем разделе.

YAML

Параметр можно настроить fetchDepth на шаге выхода конвейера.

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

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

1. Измените конвейер YAML и выберите "Дополнительные действия", "Триггеры".

   

2. Выберите YAML, Get sources(Получить источники).

   

3. Настройте параметр "Мелкое получение ". Снимите флажок "Мелкое получение", чтобы отключить неглубокое получение, или установите флажок и введите глубину, чтобы включить неглубокое получение.

   

Примечание.

Если этот параметр явно задан fetchDepth на шаге, этот параметр имеет приоритет над параметром, настроенным в checkout пользовательском интерфейсе параметров конвейера. Параметр fetchDepth: 0 извлекает весь журнал и переопределяет параметр "Мелкое получение ".

Классическое

Параметр "Мелкое получение" можно настроить из свойств задачи Get sources в конвейере.

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

Примечание.

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

Не синхронизируйте источники

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

• Git init, config и получение с помощью собственных пользовательских параметров.

• Используйте конвейер сборки для простого запуска автоматизации (например, некоторых сценариев), которые не зависят от кода в элементе управления версиями.

YAML

Вы можете настроить параметр "Не синхронизировать источники " на шаге выхода конвейера, задав параметр checkout: none.

steps:
- checkout: none  # Don't sync sources

Классическое

Выберите параметр "Не синхронизировать источники" из свойств задачи "Получить источники" в конвейере.

Примечание.

При использовании этого параметра агент также пропускает команды Git, которые очищают репозиторий.

Очистка сборки

Перед выполнением сборки можно выполнить различные формы очистки рабочего каталога локального агента.

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

Если необходимо очистить репозиторий (например, чтобы избежать проблем, вызванных остаточными файлами из предыдущей сборки), ниже приведены параметры.

Примечание.

Очистка не эффективна, если вы используете агент, размещенный корпорацией Майкрософт, так как вы будете получать новый агент каждый раз.

YAML

Параметр можно настроить clean на шаге выхода конвейера.

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

Если clean задано значение true конвейера сборки, выполняет отмену любых изменений.$(Build.SourcesDirectory) В частности, перед получением источника выполняются следующие команды Git.

git clean -ffdx
git reset --hard HEAD

Для получения дополнительных параметров можно настроить workspace параметр задания.

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

Это дает следующие параметры очистки.

• выходные данные: та же операция, что и очистка, описанная в предыдущей задаче проверки, а также удаление и повторное создание $(Build.BinariesDirectory). Обратите внимание, что $(Build.ArtifactStagingDirectory) и $(Common.TestResultsDirectory) всегда удаляются и повторно создаются до каждой сборки независимо от любого из этих параметров.

• ресурсы: удаляет и повторно создает $(Build.SourcesDirectory). Это приводит к инициализации нового локального репозитория Git для каждой сборки.

• all: удаляет и повторно создает $(Agent.BuildDirectory). Это приводит к инициализации нового локального репозитория Git для каждой сборки.

Классическое

Выберите параметр "Очистить" из свойств задачи Get sources в конвейере и выберите один из следующих параметров.

• Источники: конвейер сборки выполняет отмену любых изменений $(Build.SourcesDirectory). В частности, перед получением источника выполняются следующие команды Git.

  git clean -ffdx
  git reset --hard HEAD
  

• Источники и выходной каталог: та же операция, что и параметр "Источники" , а также удаление и повторное $(Build.BinariesDirectory)создание. Обратите внимание, что $(Build.ArtifactStagingDirectory) и $(Common.TestResultsDirectory) всегда удаляются и повторно создаются до каждой сборки независимо от любого из этих параметров.

• Каталог источников: удаляет и создает повторное создание $(Build.SourcesDirectory). Это приводит к инициализации нового локального репозитория Git для каждой сборки.

• Все каталоги сборки: удаление и повторное создание $(Agent.BuildDirectory). Это приводит к инициализации нового локального репозитория Git для каждой сборки.

Источники меток

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

YAML

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

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

Классическое

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

В формате тега можно использовать определяемые пользователем и предопределенные переменные, имеющие область "Все". Например:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

Первые четыре переменные предопределяются. My.Variableможно определить на вкладке переменных.

Конвейер сборки метки источников с тегом Git.

Некоторые переменные сборки могут дать значение, которое не является допустимой меткой. Например, переменные, такие как $(Build.RequestedFor) и $(Build.DefinitionName) могут содержать пробелы. Если значение содержит пробел, тег не создается.

После добавления источников в завершенную сборку автоматически добавляется артефакт с ссылкой refs/tags/{tag} на Git. Это дает команде дополнительную возможность трассировки и более удобный способ перехода от сборки к созданному коду. Тег считается артефактом сборки, так как он создается сборкой. При удалении сборки вручную или через политику хранения тег также удаляется.

Предопределенные переменные

При создании репозитория GitHub большинство предопределенных переменных доступны для заданий. Однако, так как Azure Pipelines не распознает удостоверение пользователя, выполняющего обновление в GitHub, следующие переменные задаются для системного удостоверения вместо удостоверения пользователя:

• Build.RequestedFor
• Build.RequestedForId
• Build.RequestedForEmail

Обновления состояния

Существует два типа состояний, которые Azure Pipelines отправляет обратно в GitHub — базовые состояния и запуски проверки GitHub. Функции проверки GitHub доступны только в приложениях GitHub.

Состояния конвейера отображаются в различных местах в пользовательском интерфейсе GitHub.

• Для PR они отображаются на вкладке бесед pr.
• Для отдельных фиксаций они отображаются при наведении указателя мыши на отметку состояния после времени фиксации на вкладке фиксаций репозитория.

Подключения PAT или OAuth GitHub

Для конвейеров с помощью подключений PAT или OAuth GitHub состояния публикуются обратно в фиксацию или pr, которая активировала выполнение. API состояния GitHub используется для публикации таких обновлений. Эти состояния содержат ограниченные сведения: состояние конвейера (сбой, успех), URL-адрес для ссылки на конвейер сборки и краткое описание состояния.

Состояния для подключений PAT или OAuth GitHub отправляются только на уровне выполнения. Другими словами, для всего выполнения можно обновить одно состояние. Если в выполнении несколько заданий, вы не можете опубликовать отдельное состояние для каждого задания. Однако несколько конвейеров могут публиковать отдельные состояния в одну фиксацию.

Проверки GitHub

Для конвейеров, настроенных с помощью приложения Azure Pipelines GitHub, состояние публикуется обратно в виде проверок GitHub. Проверки GitHub позволяют отправлять подробные сведения о состоянии конвейера и тестировании, охвате кода и ошибках. ЗДЕСЬ можно найти API проверки GitHub.

Для каждого конвейера с помощью приложения GitHub проверки публикуются обратно для общего выполнения и каждого задания в этом запуске.

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

Щелкнув ссылку "Повторно выполнить" рядом с именем проверки выполнения, azure Pipelines повторит выполнение, создающее выполнение проверки. Результирующий запуск будет иметь тот же номер выполнения и будет использовать ту же версию исходного кода, конфигурации и YAML-файла, что и начальная сборка. Будут выполняться только те задания, которые завершились сбоем в начальном запуске, и все зависимые подчиненные задания будут выполняться снова. Щелкнув ссылку "Повторно выполнить все неудачные проверки", будет иметь тот же эффект. Это то же поведение, что и нажатие кнопки "Повторить запуск" в пользовательском интерфейсе Azure Pipelines. При нажатии кнопки "Повторно выполнить все проверки" будет выполнен новый запуск с новым номером выполнения и будет собирать изменения в файле конфигурации или YAML.

Ограничения

• Для повышения производительности рекомендуется использовать не более 50 конвейеров в одном репозитории. Для приемлемой производительности рекомендуется не более 100 конвейеров в одном репозитории. Время, необходимое для обработки отправки в репозиторий, увеличивается с количеством конвейеров в этом репозитории. При отправке в репозиторий Azure Pipelines необходимо загрузить все конвейеры YAML в этом репозитории, чтобы выяснить, требуется ли выполнение любого из них, и загрузка каждого конвейера повлечет за собой штраф за производительность. Помимо проблем с производительностью, слишком много конвейеров в одном репозитории может привести к регулированию на стороне GitHub, так как Azure Pipelines может выполнять слишком много запросов в течение короткого времени.

• Использование расширений и включения шаблонов в конвейер влияет на скорость выполнения запросов API GitHub и может привести к регулированию на стороне GitHub. Перед запуском конвейера Azure Pipelines необходимо создать полный код YAML, поэтому необходимо получить все файлы шаблонов.

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

  Если вы не видите нужную ветвь в списке, введите имя требуемой ветви вручную в ветви по умолчанию для поля "Сборки вручную" и "Запланированные сборки ".

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

Вопросы и ответы

Проблемы, связанные с интеграцией GitHub, относятся к следующим категориям:

• Типы подключений: я не уверен, какой тип подключения я использую для подключения конвейера к GitHub.
• Сбой триггеров: мой конвейер не активируется при отправке обновления в репозиторий.
• Сбой при извлечении: запускается мой конвейер, но он завершается ошибкой в шаге выхода.
• Неправильная версия: выполняется мой конвейер, но используется непредвиденная версия исходного или YAML.
• Отсутствующие обновления состояния: мои PR GitHub блокируются, так как Azure Pipelines не сообщает об обновлении состояния.

Типы подключений

Чтобы устранить неполадки с триггерами, как узнать тип подключения GitHub, который я использую для конвейера?

Устранение неполадок с триггерами очень зависит от типа подключения GitHub, используемого в конвейере. Существует два способа определить тип подключения из GitHub и из Azure Pipelines.

• Из GitHub: если репозиторий настроен для использования приложения GitHub, то состояния на PR и фиксации будут проверяться. Если репозиторий настроен с помощью подключений OAuth или PAT, состояние будет "старым" стилем состояний. Быстрый способ определить, являются ли состояния проверки запусков или простых состояний, — просмотреть вкладку "Беседа" на GitHub PR.

  • Если ссылка "Сведения" перенаправляется на вкладку "Проверки", это запуск проверки и репозиторий использует приложение.
  • Если ссылка "Details" перенаправляется в конвейер Azure DevOps, то состояние является состоянием "старый стиль", а репозиторий не использует приложение.

• Из Azure Pipelines. Вы также можете определить тип подключения, проверяя конвейер в пользовательском интерфейсе Azure Pipelines. Откройте редактор конвейера. Выберите триггеры , чтобы открыть классический редактор конвейера. Затем выберите вкладку YAML и шаг "Получить источники ". Вы заметите баннер "Авторизовано" с помощью подключения: указывающее подключение службы, которое использовалось для интеграции конвейера с GitHub. Имя подключения службы — это гиперссылка. Выберите его, чтобы перейти к свойствам подключения службы. Свойства подключения службы указывают тип используемого подключения:

  • Приложение Azure Pipelines указывает подключение к приложению GitHub
  • oauth указывает подключение OAuth
  • personalaccesstoken указывает на проверку подлинности PAT

Разделы справки переключить конвейер на использование приложения GitHub вместо OAuth?

Использование приложения GitHub вместо подключения OAuth или PAT является рекомендуемой интеграцией между GitHub и Azure Pipelines. Чтобы перейти на приложение GitHub, выполните следующие действия.

1. Перейдите здесь и установите приложение в организации GitHub репозитория.
2. Во время установки вы будете перенаправлены в Azure DevOps, чтобы выбрать организацию и проект Azure DevOps. Выберите организацию и проект, содержащие классический конвейер сборки, для которого нужно использовать приложение. Этот выбор связывает установку приложения GitHub с организацией Azure DevOps. Если вы выбрали неправильно, вы можете посетить эту страницу , чтобы удалить приложение GitHub из организации GitHub и начать работу.
3. На следующей странице, которая появится, вам не нужно продолжать создание нового конвейера.
4. Измените конвейер, перейдя на страницу "Конвейеры" (например, https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build)выберите конвейер и нажмите кнопку "Изменить".
5. Если это конвейер YAML, выберите меню "Триггеры ", чтобы открыть классический редактор.
6. Выберите шаг "Получить источники" в конвейере.
7. На зеленой панели с текстом "Авторизовано с помощью подключения", выберите "Изменить" и выберите подключение приложения GitHub с тем же именем, что и организация GitHub, в которой вы установили приложение.
8. На панели инструментов выберите "Сохранить и очередь", а затем "Сохранить и очередь". Выберите ссылку на запуск конвейера, который был поставлен в очередь, чтобы убедиться, что он выполнен успешно.
9. Создайте (или закройте и повторно откройте) запрос на вытягивание в репозитории GitHub, чтобы убедиться, что сборка успешно помещена в очередь в разделе "Проверки".

Почему репозиторий GitHub не отображается для меня, чтобы выбрать в Azure Pipelines?

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

• Если вы используете приложение GitHub, ознакомьтесь с проверкой подлинности приложения GitHub.
• Если вы используете OAuth, ознакомьтесь с проверкой подлинности OAuth.
• Если вы используете PATs, ознакомьтесь с проверкой подлинности личного маркера доступа (PAT).

При выборе репозитория во время создания конвейера возникает ошибка "Репозиторий {имя репозитория} используется с приложением Azure Pipelines GitHub в другой организации Azure DevOps".

Это означает, что репозиторий уже связан с конвейером в другой организации. События CI и PR из этого репозитория не будут работать, так как они будут доставлены в другую организацию. Ниже приведены шаги, которые необходимо предпринять, чтобы удалить сопоставление с другой организацией, прежде чем продолжить создание конвейера.

1. Откройте запрос на вытягивание в репозитории GitHub и закомментируйте /azp whereего. Это сообщает о том, что репозиторий сопоставлен с организацией Azure DevOps.

2. Чтобы изменить сопоставление, удалите приложение из организации GitHub и переустановите его. При переустановке не забудьте выбрать правильную организацию при перенаправлении в Azure DevOps.

Сбой триггеров

Я только что создал новый конвейер YAML с триггерами CI/PR, но конвейер не активируется.

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

• Переопределяются ли триггеры CI или PR YAML, заданные параметрами конвейера в пользовательском интерфейсе? При редактировании конвейера выберите ... , а затем триггеры.

  

  Проверьте переопределение триггера YAML из этого параметра для типов триггеров (непрерывная интеграция или проверка запроса на вытягивание), доступных для репозитория.

  

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

  • Правильно ли настроено сопоставление между GitHub и Azure DevOps? Откройте запрос на вытягивание в репозитории GitHub и закомментируйте /azp whereего. Это сообщает о том, что репозиторий сопоставлен с организацией Azure DevOps.

    • Если организации не настроены для создания этого репозитория с помощью приложения, перейдите https://github.com/<org_name>/<repo_name>/settings/installations и завершите настройку приложения.

    • Если сообщается о другой организации Azure DevOps, то кто-то уже создал конвейер для этого репозитория в другой организации. В настоящее время у нас есть ограничение, которое мы можем сопоставить только репозиторий GitHub с одной организацией DevOps. Автоматически активируются только конвейеры в первой организации Azure DevOps. Чтобы изменить сопоставление, удалите приложение из организации GitHub и переустановите его. При переустановке не забудьте выбрать правильную организацию при перенаправлении в Azure DevOps.

• Вы используете OAuth или PAT для подключения конвейера к GitHub? Просмотрите типы подключений, чтобы определить тип подключения, который у вас есть. Если вы используете подключение GitHub, выполните следующие действия.

  1. Подключения OAuth и PAT используют веб-перехватчики для обмена данными об обновлениях в Azure Pipelines. В GitHub перейдите к параметрам репозитория, а затем к веб-перехватчикам. Убедитесь, что существуют веб-перехватчики. Обычно вы должны видеть три веб-перехватчика — push, pull_request и issue_comment. Если вы этого не сделали, необходимо повторно создать подключение службы и обновить конвейер, чтобы использовать новое подключение службы.

  2. Выберите каждый веб-перехватчик в GitHub и убедитесь, что полезные данные, соответствующие фиксации пользователя, существуют и успешно отправлены в Azure DevOps. Если событие не удалось связаться с Azure DevOps, может появиться сообщение об ошибке.

• Трафик из Azure DevOps может регулироваться GitHub. Когда Azure Pipelines получает уведомление от GitHub, он пытается связаться с GitHub и получить дополнительные сведения о репозитории и YAML-файле. Если у вас есть репозиторий с большим количеством обновлений и запросов на вытягивание, этот вызов может завершиться ошибкой из-за такого регулирования. В этом случае вы можете уменьшить частоту сборок с помощью пакетной обработки или более строгих фильтров пути или ветви.

• Приостановлен или отключен ли конвейер? Откройте редактор конвейера и выберите параметры для проверки. Если конвейер приостановлен или отключен, триггеры не работают.

• Вы обновили файл YAML в правильной ветви? При отправке обновления в ветвь файл YAML в той же ветви управляет поведением CI. Если вы отправляете обновление в исходную ветвь, то ФАЙЛ YAML, полученный из-за объединения исходной ветви с целевой ветвью, управляет поведением PR. Убедитесь, что файл YAML в правильной ветви имеет необходимую конфигурацию CI или PR.

• Правильно ли настроен триггер? При определении триггера YAML можно указать как предложения включения, так и исключения для ветвей, тегов и путей. Убедитесь, что предложение include соответствует сведениям о фиксации и что предложение исключения не исключает их. Проверьте синтаксис триггеров и убедитесь, что он является точным.

• Вы использовали переменные при определении триггера или путей? Это не поддерживается.

• Вы использовали шаблоны для файла YAML? Если это так, убедитесь, что триггеры определены в основном файле YAML. Триггеры, определенные внутри файлов шаблонов, не поддерживаются.

• Вы исключили ветви или пути, к которым вы принудили изменения? Тестирование путем отправки изменения в включенный путь в включенную ветвь. Обратите внимание, что пути в триггерах чувствительны к регистру. Убедитесь, что при указании путей в триггерах используется тот же случай, что и в реальных папках.

• Вы просто толкнули новую ветвь? Если да, новая ветвь может не запустить новый запуск. См. раздел "Поведение триггеров при создании новых ветвей".

Мои триггеры CI или PR работали нормально. Но, они перестали работать сейчас.

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

• У вас есть конфликт слияния в вашем PR? Для pr, который не активировал конвейер, откройте его и проверьте, имеет ли он конфликт слияния. Устраните конфликт слияния.

• Возникает задержка в обработке событий push-уведомлений или PR? Обычно можно проверить задержку, убедившись, что проблема связана с одним конвейером или распространена для всех конвейеров или репозиториев в проекте. Если принудительная отправка или обновление pr для любого из репозиториев отображает этот симптом, возможно, возникают задержки в обработке событий обновления. Ниже приведены некоторые причины, по которым может произойти задержка:

  • На странице состояния возникает сбой службы. Если на странице состояния отображается проблема, то наша команда должна уже начать работу над ней. Часто проверяйте страницу на наличие обновлений в этой проблеме.
  • Репозиторий содержит слишком много конвейеров YAML. Для повышения производительности рекомендуется использовать не более 50 конвейеров в одном репозитории. Для приемлемой производительности рекомендуется не более 100 конвейеров в одном репозитории. Чем больше конвейеров, тем медленнее обработка отправки в этот репозиторий. При отправке в репозиторий Azure Pipelines необходимо загрузить все конвейеры YAML в этом репозитории, чтобы выяснить, требуется ли выполнение любого из них, и каждый новый конвейер несет штраф в производительности.

Я не хочу, чтобы пользователи переопределили список ветвей для триггеров при обновлении YAML-файла. Как это сделать?

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

1. Измените конвейер в пользовательском интерфейсе Azure Pipelines.
2. Перейдите в меню "Триггеры ".
3. Выберите "Переопределить триггер непрерывной интеграции YAML" отсюда.
4. Укажите ветви, которые необходимо включить или исключить для триггера.

При выполнении этих действий все триггеры CI, указанные в YAML-файле, игнорируются.

Сбой при извлечении

В файле журнала во время выхода отображается следующая ошибка. Как это исправить?

remote: Repository not found.
fatal: repository <repo> not found

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

Неправильная версия

В конвейере используется неправильная версия ФАЙЛА YAML. Почему так?

• Для триггеров CI файл YAML, который находится в принудительной ветви, оценивается, чтобы узнать, должна ли выполняться сборка CI.
• Для триггеров PR файл YAML, полученный из-за объединения исходных и целевых ветвей PR, оценивается, чтобы узнать, должна ли выполняться сборка PR.

Отсутствующие обновления состояния

Мой pr в GitHub заблокирован, так как Azure Pipelines не обновил состояние.

Это может быть временная ошибка, которая привела к тому, что Azure DevOps не сможет взаимодействовать с GitHub. Повторите попытку входа в GitHub, если вы используете приложение GitHub. Или сделайте тривиальное обновление pr, чтобы узнать, можно ли устранить проблему.

Связанные статьи

• Запланированные триггеры
• Триггеры завершения конвейера