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

  • Статья

Azure DevOps Services

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

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

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

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

Организации

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

GitHub organization structure

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

Azure DevOps organization structure

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

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

GitHub structure mapped to Azure DevOps

Чтобы настроить идентичную структуру в 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 для реплика te пользователей 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
Запись Член Contributors
Читать Член Readers

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

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

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

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

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

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

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

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_hookread:userи user:email. Необходимо добавить в качестве участника совместной работы или добавить команду в параметры репозитория в разделе "Сотрудники и команды".

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

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

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

Триггеры CI

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

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

Ветви

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

trigger:
- main
- releases/*

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

Примечание.

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

Примечание.

Если вы используете шаблоны для создания файлов 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 пакетной обработки

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

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

Примечание.

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

Чтобы прояснить этот пример, предположим, что принудительное Amain выполнение приведенного выше конвейера привело к выполнению. При выполнении этого конвейера в репозиторий выполняются дополнительные 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 фильтрацию по всем ветвям в сочетании с фильтром пути.

Для фильтров путей поддерживаются карта Wilds. Например, можно включить все пути, соответствующие 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.

Пропуск 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 папку, а другой — при отправке обновления в код приложения. В этих случаях необходимо понять, как конвейеры активируются при создании новой ветви.

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

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

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

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

  • Если вы начинаете шаблон с * конвейера 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) вызывают выполнение конвейера при открытии запроса на вытягивание с одной из указанных целевых ветвей или при обновлении такого запроса на вытягивание.

Ветви

Вы можете указать целевые ветви при проверке запросов на вытягивание. Например, чтобы проверить запросы на вытягивание, предназначенные для этого объекта 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 с ролью "Запись".

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

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

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

    GitHub pipeline status check

Важно!

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

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

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

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

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

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

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

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

Важно!

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

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

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

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

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

Примечание.

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

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

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

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

Screenshot of centralized control settings for how pipelines build PRs from forked GitHub repositories.

Начиная с 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 собирается запустить конвейер.

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

Screenshot of an informational pipeline run.

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

  • Состояние 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. Вы можете управлять различными аспектами того, как это происходит.

Примечание.

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

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

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

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

Если вы проверка из одного репозитория, по умолчанию исходный код будет проверка в каталог с именемs. Для конвейеров YAML это можно изменить, указав checkout его.path Указанный путь относительно $(Agent.BuildDirectory). Например, если значение пути проверка out равно и $(Agent.BuildDirectory) равно mycustompathC:\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.

Обратите внимание, что значение пути проверка out не может быть задано на любом уровне каталогов выше$(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

Подмодулы

Чтобы скачать файлы из подмодулей, можно настроить 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

Конвейер сборки проверка из подмодул 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 в агенте?Ответ. Хранение учетных данных подмодула в диспетчере учетных данных Git, установленного в частном агенте сборки, обычно не действует, так как диспетчер учетных данных может предложить повторно ввести учетные данные при обновлении подмодула. Это не желательно во время автоматизированных сборок, когда взаимодействие с пользователем невозможно.

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

Важно!

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

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

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

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

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

steps:
- checkout: self
  fetchTags: true

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

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

    Screenshot of more triggers menu.

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

    Screenshot of Get sources.

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

    Screenshot of Sync tags setting.

Примечание.

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

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

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

Примечание.

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

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

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

Важно!

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

Параметр можно настроить 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 и выберите "Дополнительные действия", "Триггеры".

    Screenshot of more triggers menu.

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

    Screenshot of Get sources.

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

    Screenshot of options.

Примечание.

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

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

Примечание.

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

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

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

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

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

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

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

Примечание.

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

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

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

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

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

Примечание.

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

Параметр можно настроить 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

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

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

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

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

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

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

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

Configure Git options, YAML.

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

From the Classic editor, choose YAML > Get sources.

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

$(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/фиксации или повторно запустить все проверки, независимо от того, успешно ли выполнено первоначально.

GitHub checks rerun

Щелкнув ссылку "Повторно выполнить" рядом с именем проверки выполнения, 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, относятся к следующим категориям:

  • Типы Подключение ion: я не уверен, какой тип подключения я использую для подключения конвейера к GitHub.
  • Сбой триггеров: мой конвейер не активируется при отправке обновления в репозиторий.
  • Сбой проверка out: запускается мой конвейер, но происходит сбой в шаге проверка out.
  • Неправильная версия: выполняется мой конвейер, но используется непредвиденная версия исходного или 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, но конвейер не активируется.

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

  • Вы используете подключение приложения GitHub для подключения конвейера к GitHub? Ознакомьтесь с типами Подключение ion, чтобы определить тип подключения, который у вас есть. Если вы используете подключение к приложению 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? Ознакомьтесь с типами Подключение ion, чтобы определить тип подключения, который у вас есть. Если вы используете подключение 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-файле, игнорируются.

Сбой проверка out

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

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. Повторите попытку проверка-in GitHub, если вы используете приложение GitHub. Или сделайте тривиальное обновление pr, чтобы узнать, можно ли устранить проблему.