Share via

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

  • Статья

Azure DevOps Services

Локальный сервер GitHub Enterprise Server можно интегрировать с Azure Pipelines. Локальный сервер может быть предоставлен в Интернете или он не может быть.

Если ваш сервер GitHub Enterprise Server доступен с серверов, на которые выполняется служба Azure Pipelines, то выполните следующие действия.

  • Вы можете настроить классические конвейеры сборки и YAML
  • можно настроить триггеры CI, PR и запланированные триггеры

Если сервер GitHub Enterprise Server недоступен с серверов, на которые выполняется служба Azure Pipelines, то выполните следующие действия.

  • Вы можете настроить только классические конвейеры сборки
  • Вы можете запускать только вручную или запланированные сборки.
  • Невозможно настроить конвейеры YAML
  • Невозможно настроить триггеры CI или PR для классических конвейеров сборки

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

Доступно из Azure Pipelines

Первое, проверка заключается в том, доступен ли ваш сервер GitHub Enterprise Server из службы Azure Pipelines.

  1. В пользовательском интерфейсе Azure DevOps перейдите к параметрам проекта и выберите "Службы Подключение ions" в разделе "Конвейеры".
  2. Выберите новое подключение службы и выберите GitHub Enterprise Server в качестве типа подключения.
  3. Введите необходимые сведения для создания подключения к GitHub Enterprise Server.
  4. Выберите " Проверить" на панели подключения службы.

Если проверка проходит, серверы, на которых запущена служба Azure Pipelines, смогут связаться с локальным сервером GitHub Enterprise Server. Вы можете продолжить и настроить подключение. Затем при создании классического конвейера сборки или YAML можно использовать это подключение к службе. Вы также можете настроить триггеры CI и PR для конвейера. Большинство функций в Azure Pipelines, работающих с GitHub, также работают с GitHub Enterprise Server. Ознакомьтесь с документацией по GitHub, чтобы понять эти функции. Ниже приведены некоторые различия.

  • Интеграция между GitHub и Azure Pipelines упрощается с помощью приложения Azure Pipelines в GitHub Marketplace. Это приложение позволяет настроить интеграцию без необходимости полагаться на маркер OAuth конкретного пользователя. У нас нет аналогичного приложения, которое работает с GitHub Enterprise Server. Поэтому для настройки подключения между Azure Pipelines и сервером GitHub Enterprise необходимо использовать PAT, имя пользователя и пароль или OAuth.
  • Azure Pipelines поддерживает ряд функций безопасности GitHub для проверки вкладов внешних вилок. Например, секреты, хранящиеся в конвейере, недоступны для выполняемого задания. Эти средства защиты недоступны при работе с сервером GitHub Enterprise.
  • Триггеры комментариев недоступны на сервере GitHub Enterprise. Вы не можете использовать комментарии в запросе на вытягивание сервера GitHub Enterprise для активации конвейера.
  • Проверки GitHub недоступны на сервере GitHub Enterprise. Все обновления состояния проходят через базовые состояния.

Недоступно из Azure Pipelines

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

  • Обратитесь к ИТ-отделу, чтобы открыть сетевой путь между Azure Pipelines и GitHub Enterprise Server. Например, можно добавить исключения в правила брандмауэра, чтобы разрешить трафик из Azure Pipelines передаваться. Ознакомьтесь с разделом ip-адресов Azure DevOps, чтобы узнать, какие IP-адреса необходимо разрешить. Кроме того, необходимо иметь общедоступную запись DNS для GitHub Enterprise Server, чтобы Azure Pipelines могли разрешать полное доменное имя сервера на IP-адрес. При всех этих изменениях попытайтесь создать и проверить подключение GitHub Enterprise Server в Azure Pipelines.

  • Вместо подключения GitHub Enterprise Server можно использовать другое подключение Git . Не забудьте проверка возможность получить доступ к этому серверу Git из Azure Pipelines. С помощью этого типа подключения можно настроить только классический конвейер сборки. Триггеры CI и PR не будут работать в этой конфигурации. Запуск конвейера можно запускать только вручную или запланированные.

Доступ к доступу из размещенных корпорацией Майкрософт агентов

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

Недоступно от размещенных корпорацией Майкрософт агентов

Если простой конвейер тестирования, упоминание в приведенном выше разделе, завершается ошибкойTF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting, то сервер GitHub Enterprise Server недоступен из агентов, размещенных корпорацией Майкрософт. Это снова, вероятно, вызвано брандмауэром, блокирующим трафик с этих серверов. В этом случае у вас есть два варианта:

  • Обратитесь к ИТ-отделу, чтобы открыть сетевой путь между размещенными корпорацией Майкрософт агентами и GitHub Enterprise Server. См. раздел о сети в размещенных майкрософт агентах.

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

IP-адреса Azure DevOps

Azure Pipelines отправляет запросы на GitHub Enterprise Server:

  • Запрос списка репозиториев во время создания конвейера (классические и конвейеры YAML)
  • Поиск существующих файлов YAML во время создания конвейера (конвейеры YAML)
  • Проверка файлов YAML (конвейеры YAML)
  • Регистрация веб-перехватчика во время создания конвейера (классические и конвейеры YAML)
  • Представление редактора для файлов YAML (конвейеры YAML)
  • Разрешение шаблонов и расширение файлов YAML до выполнения (конвейеры YAML)
  • Проверьте, есть ли изменения с момента последнего запланированного выполнения (классические и конвейеры YAML)
  • Получение сведений о последней фиксации и отображении в пользовательском интерфейсе (классические и конвейеры YAML)

Вы можете наблюдать, что конвейеры YAML в основном требуют обмена данными между Azure Pipelines и GitHub Enterprise Server. Поэтому невозможно настроить конвейер YAML, если GitHub Enterprise Server не отображается в Azure Pipelines.

При использовании другого подключения Git для настройки классического конвейера отключите обмен данными между службой Azure Pipelines и GitHub Enterprise Server и используйте локальные агенты для сборки кода, вы получите пониженный интерфейс:

  • Во время создания конвейера необходимо ввести имя репозитория вручную.
  • Триггеры CI или PR нельзя использовать, так как Azure Pipelines не может зарегистрировать веб-перехватчик в GitHub Enterprise Server
  • Вы не можете использовать запланированные триггеры с параметром сборки только при наличии изменений.
  • Невозможно просмотреть сведения о последней фиксации в пользовательском интерфейсе.

Если вы хотите настроить конвейеры YAML или улучшить работу с классическими конвейерами, важно включить обмен данными с Azure Pipelines на GitHub Enterprise Server.

Чтобы разрешить трафик из Azure DevOps для доступа к GitHub Enterprise Server, добавьте IP-адреса или теги службы, указанные в входящих подключениях к списку разрешений брандмауэра. Если вы используете ExpressRoute, обязательно включите диапазоны IP-адресов ExpressRoute в список разрешений брандмауэра.

Ограничения

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

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

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

  • Сбои триггеров: мой конвейер не активируется при отправке обновления в репозиторий.
  • Сбой проверка out: запускается мой конвейер, но происходит сбой в шаге проверка out.
  • Неправильная версия: выполняется мой конвейер, но используется непредвиденная версия исходного или YAML.

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

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

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

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

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

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

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

  • Вы обновили файл 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 в этом репозитории, чтобы выяснить, требуется ли выполнение любого из них, и каждый новый конвейер несет штраф в производительности.
    • Экземпляр GitHub Enterprise Server может быть недоопробован, замедляя обработку запросов из Azure Pipelines. Дополнительные сведения об оборудовании для GitHub Enterprise Server.

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

Вы используете агенты, размещенные корпорацией Майкрософт? В этом случае эти агенты могут не получить доступ к серверу GitHub Enterprise Server. Дополнительные сведения см. в разделе "Недоступно" от агентов, размещенных корпорацией Майкрософт.

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

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

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