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

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

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

Ветвь

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

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

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

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

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

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 }}

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

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

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

$(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) для сборок.
• Ветви: указывает состояние последней сборки для каждой ветви.

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

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

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

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

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

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

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

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

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

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

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

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

Если основной репозиторий и подмодулы находятся в репозитории 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.

Извлеките файлы из 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 могут не быть.

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://[email protected]/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 fetch --depth=n Если репозиторий велик, этот параметр может повысить эффективность конвейера сборки. Ваш репозиторий может быть большим, если он используется в течение длительного времени и имеет большой журнал. Он также может быть большим, если вы добавили и позже удалили большие файлы.

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

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

Предпочитать 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.