Подключение репозитория Azure DevOps

Orbit развёртывает репозитории из Azure Repos, хостинга git внутри Azure DevOps. Подключитесь один раз, выберите репозиторий, и каждый push будет собран и развёрнут. Это руководство охватывает оба способа подключения, выбор репозитория и два отличия Azure от других провайдеров.

Два способа подключения и почему их два

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

• Вход через Microsoft. Один клик, ничего не нужно копировать и вставлять. Доступно, когда ваша организация разрешает сторонние приложения.
• Личный токен доступа. Работает для любой организации, включая те, которые блокируют приложения. Вы вводите имя организации и токен, который создали в Azure DevOps.

Оба способа предоставляют доступ к одним и тем же функциям. Ни один из них не является сокращённой версией другого.

Перед началом

Вариант A: вход через Microsoft

1. В KPanel нажмите Orbit на левой боковой панели.
2. Нажмите New project.
3. Оставьте режим установленным на Import Git Repo.
4. Выберите вкладку Azure DevOps, затем нажмите Connect Azure DevOps.

Вы будете перенаправлены на Microsoft для входа и подтверждения доступа. Подтвердите и вы вернётесь в KPanel с загруженными репозиториями.

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

Вариант B: личный токен доступа

Сначала создайте токен в Azure DevOps.

1. В Azure DevOps откройте User settings, затем Personal access tokens, затем New Token.
2. Выберите организацию, из которой вы хотите развёртывать.
3. Выдайте эти три области доступа и не более:
   • Code (Read) чтобы Orbit мог перечислить ваши репозитории и скачать коммит, который он собирает.
   • Code (Status) чтобы результат сборки появился на коммите и на pull request.
   • Service Hooks (Read and write) чтобы Orbit мог подписаться на ваши push.
4. Скопируйте токен. Azure показывает его только один раз.

Затем в KPanel:

1. Откройте Orbit, затем New project, затем вкладку Azure DevOps.
2. В разделе Connect with a personal access token введите имя вашей organisation. Это часть адреса вашего репозитория сразу после dev.azure.com, так что для https://dev.azure.com/contoso/web-platform/_git/storefront организация это contoso.
3. Вставьте токен и нажмите Connect Azure DevOps.

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

Ваш токен шифруется перед сохранением и используется только для указанной вами организации.

Выбор репозитория

Ваши репозитории появляются в виде списка с названием organisation / project / repository. Репозитории Azure содержат три части, а не две, потому что два проекта в одной организации могут содержать репозитории с одинаковыми именами.

Нажмите Select рядом с нужным, затем завершите проект обычным образом: имя, фреймворк, настройки сборки, переменные окружения.

Если репозиторий не отображается

• Проверьте организацию. Личный токен доступа принадлежит ОДНОЙ организации, поэтому репозиторий в другой организации не появится. Подключите и эту организацию.
• Проверьте ваши права доступа на репозиторий в Azure DevOps.
• Проверьте, не отключен ли репозиторий в Azure. Orbit не перечисляет отключённые репозитории, потому что они не могут быть собраны.

Два отличия Azure

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

Корневая директория монорепозитория не пропускает push

У других провайдеров Orbit читает список файлов, которые изменил каждый push, и проект монорепозитория может пропустить сборку, если ничего в его корневой директории не изменилось. Azure не отправляет этот список. Orbit поэтому собирает при каждом push, а не гадает, потому что угадать иначе означало бы молча пропустить развёртывания, которые вы ожидали.

Ваша настройка корневой директории всё ещё определяет, где запускается сборка. Она просто не фильтрует дополнительно, какие push вызывают сборку.

Pull request из форков не собираются

Orbit собирает предпросмотр pull request с переменными Preview окружения вашего проекта. Это безопасно для pull request из вашего собственного репозитория и небезопасно для pull request из форка, который является предложением от кого-то без отношения к вашей учётной записи.

На GitHub Orbit может предложить предпросмотр форка, потому что GitHub публикует предлагаемый коммит внутри вашего собственного репозитория, так что нам никогда не нужно проходить аутентификацию против копии участника. Azure не публикует эквивалент, поэтому Orbit отказывает fork pull request и указывает на это в коммите, вместо того чтобы оставлять предпросмотр, который никогда не появится.

Pull request из веток внутри вашего собственного репозитория собираются обычным образом.

Что дальше

Push на вашу production ветку и Orbit собирает и развёртывает. Результат сборки отправляется обратно на коммит в Azure DevOps, так что он отображается на коммите и на любом pull request, к которому принадлежит коммит, и ваши политики ветвей могут требовать его.

См. также

• Что такое Orbit?
• Развертывание вашего проекта
• Подключение репозитория GitHub