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

Возможности конвейеров для репозиториев Git

  • Статья

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

При редактировании конвейера, использующего репозиторий Git ( в проекте Azure DevOps, GitHub Enterprise Server, Bitbucket Cloud или другом репозитории Git), у вас есть следующие параметры.

Функция Azure Pipelines Azure DevOps Server 2019 и выше TFS 2018
Ветвь Да Да Да
Очистить Да Да Да
Источники тегов или меток Проект; Только классическая версия Командный проект Командный проект
Сообщить состояние сборки Да Да Да
Ознакомьтесь с подмодулами Да Да Да
Извлеките файлы из LFS Да Да Да
Клонирование второго репозитория Да Да Да
Не синхронизируйте источники Да Да Да
Неглубокое получение Да Да Да

Примечание.

Нажмите кнопку "Дополнительные параметры" в задаче "Получить источники", чтобы просмотреть некоторые из указанных выше параметров.

Ветвь

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

Очистка локального репозитория агента

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

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

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

Примечание.

Очистка не эффективна, если вы используете агент, размещенный корпорацией Майкрософт, так как вы будете получать новый агент каждый раз. При использовании локальных агентов в зависимости от того, как настроены пулы агентов, вы можете получить новый агент для последующих запусков конвейера (или этапов или заданий в одном конвейере), поэтому не гарантирует, что последующие запуски, задания или этапы смогут получить доступ к выходным данным из предыдущих запусков, заданий или этапов.

Примечание.

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

Azure Pipelines, Azure DevOps Server 2019 и более поздней версии

Существует несколько различных вариантов очистки для конвейеров YAML.

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

parameters:
- name: clean
  displayName: Checkout clean
  type: boolean
  default: true
  values:
  - false
  - true

trigger:
- main

pool: FabrikamPool
#  vmImage: 'ubuntu-latest'

steps:
- checkout: self
  clean: ${{ parameters.clean }}

По умолчанию задано true значение, но может быть переопределено при выполнении конвейера вручную, снимите флажок "Очистка флажка", clean добавленного для параметра среды выполнения.

Источники меток

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

Примечание.

Эту функцию можно использовать только в том случае, если исходный репозиторий в сборке — это репозиторий GitHub, репозиторий Git или TFVC из проекта.

В формате метки можно использовать определяемые пользователем и предопределенные переменные, имеющие область "Все". Например:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

Первые четыре переменные предопределяются. My.Variableможно определить на вкладке переменных.

Конвейер сборки метки источников с тегом Git.

Некоторые переменные сборки могут дать значение, которое не является допустимой меткой. Например, переменные, такие как $(Build.RequestedFor) и $(Build.DefinitionName) могут содержать пробелы. Если значение содержит пробел, тег не создается.

После добавления источников в завершенную сборку автоматически добавляется артефакт с ссылкой refs/tags/{tag} на Git. Это дает команде дополнительную возможность трассировки и более удобный способ перехода от сборки к созданному коду. Тег считается артефактом сборки, так как он создается сборкой. При удалении сборки вручную или через политику хранения тег также удаляется.

Состояние сборки отчета (Azure Pipelines, TFS 2018 и более поздней версии)

У вас есть возможность предоставить команде представление о состоянии сборки из удаленного исходного репозитория.

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

  • Файлы: указывает состояние последней сборки для выбранной ветви.
  • Фиксации. Указывает состояние сборки каждой фиксации (это требует включения триггера непрерывной интеграции (CI) для сборок.
  • Ветви: указывает состояние последней сборки для каждой ветви.

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

GitHub

Если источники находятся в GitHub, этот параметр публикует состояние сборки в GitHub с помощью api проверки или состояния GitHub. Если сборка активируется из запроса на вытягивание GitHub, вы можете просмотреть состояние на странице запросов на вытягивание GitHub. Это также позволяет задавать политики состояния в GitHub и автоматизировать слияние. Если сборка активируется непрерывной интеграцией (CI), вы можете просмотреть состояние сборки в фиксации или ветви в GitHub.

Другие типы удаленных репозиториев Git

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

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

Если вы извлекаете один репозиторий, по умолчанию исходный код будет извлечен в каталог с именем s. Для конвейеров YAML это можно изменить, указав checkout его.path Указанный путь относительно $(Agent.BuildDirectory). Например, если значение пути к извлечению и имеет значение mycustompath $(Agent.BuildDirectory) C:\agent\_work\1, исходный код будет извлечен в .C:\agent\_work\1\mycustompath

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

Обратите внимание, что значение пути к выходу не может быть задано на любом уровне каталога выше $(Agent.BuildDirectory), поэтому path\..\anotherpath приведет к допустимому пути извлечения (т C:\agent\_work\1\anotherpath. е.), но значение ..\invalidpath , например, не будет (т. е. C:\agent\_work\invalidpathне ).

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

Примечание.

Путь к извлечению можно указать только для конвейеров YAML. Дополнительные сведения см. в разделе "Возврат" в схеме YAML.

Извлечение подмодулей

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

Примечание.

Дополнительные сведения о синтаксисе YAML для проверки подмодул см. в разделе "Извлечение" в схеме YAML.

Конвейер сборки будет проверять подмодулы Git до тех пор, пока они:

  • Unauthenticated: общедоступный, не прошедший проверку подлинности репозиторий без учетных данных, необходимых для клонирования или получения.

  • Проверкой подлинности:

    • Содержится в том же проекте, организации GitHub или учетной записи Bitbucket Cloud, что и репозиторий Git, указанный выше.

    • Добавлен URL-адрес относительно основного репозитория. Например, это будет извлечено: git submodule add /../../submodule.git mymodule этот не будет извлечен: git submodule add https://dev.azure.com/fabrikamfiber/_git/ConsoleApp mymodule

Подмодулы, прошедшие проверку подлинности

Примечание.

Убедитесь, что вы зарегистрировали подмодулы с помощью ПРОТОКОЛА HTTPS и не используете SSH.

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

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

  • Коллекция проектов для использования учетной записи службы сборки коллекции проектов

  • Текущий проект для использования учетной записи службы сборки проекта.

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

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

Альтернатива использованию параметра подмодулы checkout

В некоторых случаях вы не можете использовать параметр "Вычислить подмодулы ". У вас может быть сценарий, когда для доступа к подмодулям требуется другой набор учетных данных. Это может произойти, например, если основной репозиторий и вложенные репозитории не хранятся в той же организации Azure DevOps или службе Git.

Если вы не можете использовать параметр подмодулы checkout, вместо этого можно использовать настраиваемый шаг скрипта для получения вложенных модулей. Сначала получите личный маркер доступа (PAT) и префикс его pat:. Затем в кодировке base64 эта префиксированная строка создается базовый маркер проверки подлинности. Наконец, добавьте этот скрипт в конвейер:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: basic <BASE64_ENCODED_TOKEN_DESCRIBED_ABOVE>" submodule update --init --recursive

Обязательно замените "<BASIC_AUTH_TOKEN>" маркером в кодировке Base64.

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

Примечание.

Вопрос. Почему я не могу использовать диспетчер учетных данных Git в агенте? A: Хранение учетных данных подмодула в диспетчере учетных данных Git, установленного в частном агенте сборки, обычно не действует, так как диспетчер учетных данных может повторно ввести учетные данные при обновлении подмодула. Это не желательно во время автоматизированных сборок, когда взаимодействие с пользователем невозможно.

Извлеките файлы из LFS

Выберите, нужно ли скачать файлы из большого хранилища файлов (LFS).

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

В сборке YAML добавьте шаг получения с lfs заданным значением true:

steps:
- checkout: self
  lfs: true

Если вы используете TFS или используете Azure Pipelines с локальным агентом, необходимо установить git-lfs агент для работы этого параметра. Если размещенные агенты используют Windows, попробуйте использовать System.PreferGitFromPath переменную, чтобы гарантировать, что конвейеры используют версии git и git-lfs, установленные на компьютере. Дополнительные сведения см. в статье о том, какая версия Git выполняется агентом?

Использование Git LFS с подмодулами

Если подмодул содержит файлы LFS, необходимо настроить Git LFS перед извлечением подмодул. Агенты macOS и Linux, размещенные в Майкрософт, предварительно настроены таким образом. Агенты Windows и локальные агенты macOS или Linux могут не быть.

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

steps:
- script: |
    git config --global --add filter.lfs.required true
    git config --global --add filter.lfs.smudge "git-lfs smudge -- %%f"
    git config --global --add filter.lfs.process "git-lfs filter-process"
    git config --global --add filter.lfs.clean "git-lfs clean -- %%f"
  displayName: Configure LFS for use with submodules
- checkout: self
  lfs: true
  submodules: true
# ... rest of steps ...

Клонирование второго репозитория

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

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

git clone https://github.com/Microsoft/TypeScript.git

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

Azure Repos

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

- script: | 
    git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" https://organization@dev.azure.com/project/FabrikamFiber/_git/reponame

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

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

Примечание.

Используйте секретную переменную для безопасного хранения учетных данных.

Секретные переменные не становятся доступными для сценариев в качестве переменных среды. См. раздел "Секретные переменные " о том, как сопоставить их.

Для Azure Repos можно использовать личный маркер доступа с разрешением Code (Read). Отправьте его в качестве поля пароля в заголовке авторизации "Базовый" без имени пользователя. (Другими словами, base64-кодирует значение :<PAT>, включая двоеточие.)

AUTH=$(echo -n ":$REPO_PAT" | openssl base64 | tr -d '\n')
git -c http.<repo URL>.extraheader="AUTHORIZATION: basic $AUTH" clone <repo URL> --no-checkout --branch master

Не синхронизируйте источники

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

  • Git init, config и получение с помощью собственных пользовательских параметров.

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

Если вы хотите отключить загрузку источников:

  • Azure Pipelines, TFS 2018 и более поздней версии: щелкните "Дополнительные параметры", а затем выберите "Не синхронизировать источники".

Примечание.

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

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

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

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

Примечание.

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

После выбора флажка, чтобы включить этот параметр, в поле глубины укажите количество фиксаций.

Совет

Указанная Agent.Source.Git.ShallowFetchDepth ниже переменная также работает и переопределяет элементы управления флажка. Таким образом можно изменить параметр при очереди сборки.

Предпочитать Git из пути

По умолчанию агент Windows использует версию Git, которая входит в состав программного обеспечения агента. Корпорация Майкрософт рекомендует использовать версию Git, которая входит в состав агента, но у вас есть несколько вариантов переопределить это поведение по умолчанию и использовать версию Git, установленную на компьютере агента в пути.

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

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

Этот параметр всегда имеет значение true в агентах, отличных от Windows.

Параметры триггера для других Git

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

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

Какие протоколы могут использовать агент сборки с Git?

Агент поддерживает ПРОТОКОЛ HTTPS.

Агент пока не поддерживает SSH. См. раздел "Разрешить сборку" использовать проверку подлинности SSH при проверке подмодул Git.

Я использую Team Foundation Server локально и не вижу некоторые из этих функций. Почему?

Некоторые из этих функций доступны только в Azure Pipelines и пока недоступны в локальной среде. Некоторые функции доступны в локальной среде, если вы выполнили обновление до последней версии Team Foundation Server.