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

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

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

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

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

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

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

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

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

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

В следующем примере три репозитория объявляются как ресурсы репозитория. Репозиторий Azure Repos Git в другой организацииGitHub и Bitbucket Cloud для ресурсов репозитория требуются подключения , указанные в качестве 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 свойством в ресурсе репозитория) используются для папок, так как в шаге извлечения не path указано. Дополнительные сведения о именах и расположениях папок репозитория см. в следующем разделе пути к выходу.

Встроенный синтаксический контроль

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

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

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

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

• Один репозиторий: если у вас есть один 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\toolsC:\agent\_work\1\s\code.

  Примечание.

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

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

Репозиторий рабочей области

Если в конвейере используется несколько checkout шагов (и разные пути для каждого) можно использовать корневой каталог одного репозитория в качестве рабочего каталога по умолчанию. В этом случае можно задать для workspaceRepo входные данные true для соответствующего шага checkout.

- checkout: git://project/first
  path: repo/first-repo

- checkout: git://project/second
  path: repo/second-repo
  workspaceRepo: true

- pwsh: pwd
# Expected output: $(Pipeline.Workspace)/repo/second-repo

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

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

Если используется встроенный синтаксис, назначьте ссылку путем @<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.

Параметризация ветви с помощью встроенного синтаксиса

Определите параметр среды выполнения и сослаться на него с выражением шаблона в строковом значении извлечений:

parameters:
  - name: branch
    type: string
    default: 'main'

steps:
  - checkout: git://MyProject/MyRepo@${{ parameters.branch }}

Параметризация ветви с помощью ресурса репозитория

ref Используйте свойство в ресурсе репозитория, чтобы задать ветвь из параметра:

parameters:
  - name: branch
    type: string
    default: 'main'

resources:
  repositories:
    - repository: MyRepo
      type: git
      name: MyProject/MyRepo
      ref: ${{ parameters.branch }}

steps:
  - checkout: MyRepo

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

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

steps:
- checkout: MyGitHubRepo

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

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

steps:
- checkout: MyGitHubRepo

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

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

При извлечении нескольких репозиториев некоторые сведения о 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"

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

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

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

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

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

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

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

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