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

Azure DevOps Services | Azure DevOps Server 2022 г. - Azure DevOps Server 2019 г. | TFS 2018

Примечание

В Microsoft Team Foundation Server (TFS) 2018 и предыдущих версий конвейеры сборки и выпуска называются определениями, выполнения называются сборками, подключения к службам называются конечными точками служб, этапы называются средами, а задания называются этапами.

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

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

Примечание

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

Ветвь

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

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

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

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

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

Примечание

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

Примечание

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

YAML

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

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

• Шаг checkout имеет параметр clean . Если задано значение true, конвейер выполняется execute git clean -ffdx && git reset --hard HEAD перед получением репозитория. Дополнительные сведения см. в разделе Checkout.
• Параметр workspace для job имеет несколько параметров очистки (выходные данные, ресурсы и все). Дополнительные сведения см. в разделе Рабочая область.
• В пользовательском интерфейсе параметров конвейера есть параметр Clean , который, если задано значение true, эквивалентно указанию clean: true для каждого checkout шага в конвейере. Чтобы настроить параметр Clean, выполните следующие действия.

  1. Измените конвейер, выберите ..., а затем — Триггеры.

     

  2. Выберите YAML, Получить источники и настройте нужный параметр Очистка . Значение по умолчанию — true.

     

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

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 но его можно переопределить при выполнении конвейера вручную, сняв флажок Извлечь очистку, добавленный для параметра среды выполнения.

Конвейеры YAML поддерживаются в Azure DevOps Server 2019 и более поздних версиях.

Классический

Azure Pipelines, TFS 2018, TFS 2017.2, TFS 2017.3

Выберите один из следующих вариантов.

• Источники: конвейер сборки выполняет отмену всех изменений в $(Build.SourcesDirectory). В частности, перед получением источника выполняются следующие команды Git.

  git clean -ffdx
  git reset --hard HEAD
  

• Источники и выходной каталог: та же операция, что и параметр Источники выше, плюс: удаляет и повторно создает $(Build.BinariesDirectory). Обратите внимание, что $(Build.ArtifactStagingDirectory) и $(Common.TestResultsDirectory) всегда удаляются и повторно создаются перед каждой сборкой независимо от любого из этих параметров.

• Каталог Sources: удаляет и повторно создает $(Build.SourcesDirectory). Это приводит к инициализации нового локального репозитория Git для каждой сборки.

• Все каталоги сборки: удаляет и повторно создает $(Agent.BuildDirectory). Это приводит к инициализации нового локального репозитория Git для каждой сборки.

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

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

Примечание

Эту функцию можно использовать только в том случае, если исходный репозиторий в сборке является репозиторием 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), в противном случае вложенная папка шага извлечения будет очищена очисткой другого репозитория. Обратите внимание, что этот случай допустим, если для параметра clean задано значение true.repo1

Примечание

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

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

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

Примечание

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

Конвейер сборки проверка из подмодулей Git, если они:

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

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

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

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

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

Примечание

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

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

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

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

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

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

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

Альтернатива использованию параметра "Подмодулы для оформления заказа"

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

Если вы не можете использовать параметр Извлечение подмодулей , вместо этого можно использовать настраиваемый шаг скрипта для получения подмодулей. Сначала получите личный маркер доступа (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 запускается моим агентом?

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

Если подмодул содержит 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 можно использовать личный маркер доступа с разрешением код (чтение). Отправьте его в качестве поля пароля в заголовке авторизации "Базовый" без имени пользователя. (Другими словами, в кодировке 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 с помощью собственных настраиваемых параметров.

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

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

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

Примечание

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

Неглубокая выборка

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

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

Примечание

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

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

Совет

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

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

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

• Задайте переменную конвейера с именем System.PreferGitFromPath в true конвейерах.
• На локальных агентах можно создать файл с именем .env в корневом каталоге агента и добавить System.PreferGitFromPath=true строку в файл. Дополнительные сведения см. в статье Разделы справки задать разные переменные среды для каждого отдельного агента?

Чтобы просмотреть версию 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.