Поделиться через

Ознакомьтесь с несколькими репозиториями в конвейере

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

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

Указание нескольких репозиториев

Репозитории можно указать в качестве ресурса репозитория или в соответствии с checkout шагом.

Поддерживаются следующие типы репозитория.

Azure Repos Git (git)

  • Azure DevOps Server (ограничено репозиториями в той же организации)
  • Azure DevOps Services

GitHub (github)

  • Azure DevOps Services

GitHubEnterprise (githubenterprise)

  • Azure DevOps Services

Bitbucket Cloud (bitbucket)

  • Azure DevOps Services

Внимание

Только репозитории Azure Repos Git (git) в той же организации, что и конвейер, поддерживаются для нескольких репозиториев проверка out в Azure DevOps Server.

Примечание.

Azure Pipelines предоставляет параметры ограничения заданий область для репозиториев Azure Repos Git. Чтобы проверка репозитории Azure Repos Git, размещенные в другом проекте, необходимо настроить ограничение область задания, чтобы разрешить доступ. Дополнительные сведения см. в разделе "Ограничение авторизации задания" область.

Поддерживаются следующие сочетания checkout шагов.

Никаких checkout шагов

Поведение по умолчанию, как если бы checkout: self было первым шагом, и текущий репозиторий проверка отключен.

Один checkout: none шаг

Репозитории не синхронизированы или проверка отключены.

Один checkout: self шаг

Текущий репозиторий проверка отключен.

Один checkout шаг, который не является или не self является none

Указанный репозиторий проверка не используетсяself.

Несколько checkout шагов

Каждый указанный репозиторий проверка в папку с именем репозитория, если на шаге не указано другое path checkout. Чтобы проверка в self качестве одного из репозиториев, используйте checkout: self в качестве одного из checkout шагов.

Примечание.

При извлечении репозиториев Git Azure Repos, отличных от репозиториев, содержащих конвейер, перед первым запуском конвейера может отобразиться запрос на авторизацию доступа к такому ресурсу. Дополнительные сведения см. в статье "Почему мне предлагается авторизовать ресурсы в первый раз, когда я пытаюсь проверка другой репозиторий?", в разделе часто задаваемых вопросов.

Определение ресурса репозитория

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

Тип репозитория Подключение службы
Облако Bitbucket Bitbucket Cloud
GitHub GitHub
GitHub Enterprise Server GitHub Enterprise Server
Репозитории Azure Repos Git в организации, отличной от конвейера Azure Repos/Team Foundation Server

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

В следующем примере три репозитория объявляются как ресурсы репозитория. Репозиторий Azure Repos Git в другой организации, GitHub и Ресурсах облачного репозитория Bitbucket требуют подключения к службе, которые указаны в качестве endpoint для этих ресурсов репозитория. В этом примере есть четыре checkout шага, которые проверка из трех репозиториев, объявленных как ресурсы репозитория, а также текущий self репозиторий, содержащий yamL конвейера.

resources:
  repositories:
  - repository: MyGitHubRepo # The name used to reference this repository in the checkout step
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
  - repository: MyBitbucketRepo
    type: bitbucket
    endpoint: MyBitbucketServiceConnection
    name: MyBitbucketOrgOrUser/MyBitbucketRepo
  - repository: MyAzureReposGitRepository # In a different organization
    endpoint: MyAzureReposGitServiceConnection
    type: git
    name: OtherProject/MyAzureReposGitRepo

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- checkout: self
- checkout: MyGitHubRepo
- checkout: MyBitbucketRepo
- checkout: MyAzureReposGitRepository

- script: dir $(Build.SourcesDirectory)

Если репозиторий self называетсяCurrentRepo, script команда создает следующие выходные данные: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo В этом примере имена репозиториев (как указано name свойством в ресурсе репозитория) используются для папок, так как в шаге проверка out не path указано. Дополнительные сведения о именах и расположениях папок репозитория см. в следующем разделе пути к выходу.

Встроенный синтаксис проверка out

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

Примечание.

Только репозитории Azure Repos Git в той же организации могут использовать встроенный синтаксис. Репозитории Azure Repos Git в другой организации и другие поддерживаемые типы репозиториев требуют подключения к службе и должны быть объявлены в качестве ресурса репозитория.

steps:
- checkout: self
- checkout: git://MyProject/MyRepo # Azure Repos Git repository in the same organization

Примечание.

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

Если вы используете репозиторий Azure Repos Git по умолчанию (с тем же именем, что и проект), используйте формат - checkout: git://MyRepo/MyRepo.

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

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

  • Один репозиторий: если у вас есть один checkout шаг в задании или нет проверка шага, который эквивалентенcheckout: self, исходный код проверка в каталог, который называется s вложенной папкой(Agent.BuildDirectory). Если (Agent.BuildDirectory) это C:\agent\_work\1так, код проверка включенC:\agent\_work\1\s.

  • Несколько репозиториев. Если у вас несколько checkout шагов в задании, исходный код проверка в каталоги с именем репозиториев в качестве вложенной s (Agent.BuildDirectory)папки. Если (Agent.BuildDirectory) это C:\agent\_work\1 и ваши репозитории именуютсяtools, и codeкод проверка в C:\agent\_work\1\s\tools него.C:\agent\_work\1\s\code

    Примечание.

    Если на шаге нет path , checkout имя репозитория используется для папки, а не repository значение, которое используется для ссылки на репозиторий на шаге checkout .

Если для шага задано path значение, используется этот путь относительно (Agent.BuildDirectory).checkout

Примечание.

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

Извлечение определенного ссылок

Ветвь по умолчанию проверка, если вы не назначите конкретный ссылочный элемент.

Если используется встроенный синтаксис, назначьте ссылку путем @<ref>добавления. Например:

- checkout: git://MyProject/MyRepo@features/tools # checks out the features/tools branch
- checkout: git://MyProject/MyRepo@refs/heads/features/tools # also checks out the features/tools branch
- checkout: git://MyProject/MyRepo@refs/tags/MyTag # checks out the commit referenced by MyTag.

При использовании ресурса репозитория укажите ссылку с помощью ref свойства. В следующем примере проверка из features/tools/ ветви указанного репозитория.

resources:
  repositories:
  - repository: MyGitHubRepo
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
    ref: features/tools

steps:
- checkout: MyGitHubRepo

В следующем примере теги используются для проверка фиксации, на которую ссылается MyTagссылка.

resources:
  repositories:
  - repository: MyGitHubRepo
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
    ref: refs/tags/MyTag

steps:
- checkout: MyGitHubRepo

Триггеры

Конвейер можно активировать при отправке self обновления в репозиторий или в любой из репозиториев, объявленных как ресурсы. Это полезно, например, в следующих сценариях:

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

Внимание

Триггеры ресурсов репозитория работают только для репозиториев Azure Repos Git в той же организации и когда self тип репозитория — Azure Repos Git. Они не работают для ресурсов репозитория GitHub или Bitbucket.

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

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

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

При активации конвейера Azure Pipelines необходимо определить версию YAML-файла, которую следует использовать, и версию для каждого репозитория, который следует проверка. Если изменение self репозитория активирует конвейер, то фиксация, активировающая конвейер, используется для определения версии ФАЙЛА YAML. Если изменение любого другого ресурса репозитория активирует конвейер, используется последняя версия YAML из ветвь по умолчанию репозиторияself.

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

  • Build.Repository.ID
  • Build.Repository.Name
  • Build.Repository.Provider
  • Build.Repository.Uri
  • Build.SourceBranch
  • Build.SourceBranchName
  • Build.SourceVersion
  • Build.SourceVersionMessage

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

Рассмотрим следующий пример, где self репозиторий содержит файл YAML и репозитории A и B содержит дополнительный исходный код.

trigger:
- main
- feature

resources:
  repositories:
  - repository: A
    type: git
    name: MyProject/A
    ref: main
    trigger:
    - main

  - repository: B
    type: git
    name: MyProject/B
    ref: release
    trigger:
    - main
    - release
steps:
- checkout: self
- checkout: A
- checkout: B

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

Изменения, внесенные в Триггер конвейера Версия YAML Версия self Версия A Версия B
main в self. Да фиксация из main этого триггера конвейера фиксация из main этого триггера конвейера последняя версия из main последняя версия из release
feature в self. Да фиксация из feature этого триггера конвейера фиксация из feature этого триггера конвейера последняя версия из main последняя версия из release
main в A. Да последняя версия из main последняя версия из main фиксация из main этого триггера конвейера последняя версия из release
main в B. Да последняя версия из main последняя версия из main последняя версия из main фиксация из main этого триггера конвейера
release в B. Да последняя версия из main последняя версия из main последняя версия из main фиксация из release этого триггера конвейера

Вы также можете активировать конвейер при создании или обновлении запроса на вытягивание в любом из репозиториев. Для этого объявите ресурсы репозитория в файлах YAML, как в приведенных выше примерах, и настройте политику ветви в репозитории (только Azure Repos).

Сведения о репозитории

При проверка нескольких репозиториев некоторые сведения о self репозитории доступны в виде переменных. При использовании триггеров с несколькими репозиториями некоторые из этих переменных содержат сведения о триггерном репозитории. Сведения обо всех репозиториях, потребляемых заданием, доступны как объект resources.repositoriesконтекста шаблона.

Например, чтобы получить ссылку наself репозиторий, можно написать конвейер следующим образом:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: |
    echo "Tools version: $TOOLS_REF"

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

Почему я не могу проверка репозиторий из другого проекта? (Почему не удается оформить заказ на репозиторий из другого проекта? Раньше все работало.)

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

Почему мне предлагается авторизовать ресурсы при первом попытке проверка из другого репозитория?

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

This pipeline needs permission to access a resource

Authorize resource

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

Waiting for review

Permit access

Дополнительные сведения см. в разделе Устранение неполадок с авторизацией для конвейера YAML.