Создание репозиториев 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-пути. Например:

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

Пользователи 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

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

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

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

Разрешения репозитория 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 предоставляет разрешения командам, вы можете создать соответствующие команды в Teams разделе параметров проекта Azure DevOps. Затем добавьте команды в группы безопасности выше, как и пользователи.

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

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

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

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

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

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

Проверка подлинности приложения 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 запрашивает следующие разрешения во время установки:

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

trigger:
- main
- releases/*

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

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

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

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

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

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

# A pipeline with no CI trigger
trigger: none

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

pr:
- main
- releases/*

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

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

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

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

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

# no PR triggers
pr: none

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы можете централизованно определить, как конвейеры создают 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 в комментариях:

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

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

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

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

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

Подмодулы

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.

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

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

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

steps:
- checkout: self
  fetchTags: true

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

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

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

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

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 init, config и получение с помощью собственных пользовательских параметров.

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

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

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

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

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

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

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 clean -ffdx
git reset --hard HEAD

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

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

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