Возможности конвейеров для репозиториев 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).

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

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

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

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

Примечание.

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

YAML

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

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

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

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

     

  2. Выберите YAML, Get sources и настройте нужный параметр "Очистить ". Значение по умолчанию: true.

     

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

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

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

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) всегда удаляются и повторно создаются до каждой сборки независимо от любого из этих параметров.

• Каталог источников: удаляет и создает повторное создание $(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). Например, если значение пути проверка out равно и $(Agent.BuildDirectory) равно mycustompathC:\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.

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

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

Примечание.

Путь проверка out можно указать только для конвейеров 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 в агенте?Ответ. Хранение учетных данных подмодула в диспетчере учетных данных Git, установленного в частном агенте сборки, обычно не действует, так как диспетчер учетных данных может предложить повторно ввести учетные данные при обновлении подмодула. Это не желательно во время автоматизированных сборок, когда взаимодействие с пользователем невозможно.

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

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

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

В сборке YAML добавьте шаг проверка out с 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

Клонировать несколько репозиториев в одном проекте с конвейером можно с помощью нескольких репозиториев проверка out.

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

Примечание.

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

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

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

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

Примечание.

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

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

Совет

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

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

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

• Задайте переменную конвейера с именем System.PreferGitFromPathtrue в конвейерах.
• В локальных агентах можно создать файл с именем 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.