Сборка Azure Repos репозиториев Git или TFS Git

  • Статья

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

Примечание

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

Azure Pipelines может автоматически создавать и проверять каждый запрос на вытягивание и фиксировать его в репозитории Azure Repos Git.

Выбор репозитория для сборки

Чтобы создать новый конвейер, сначала выберите репозиторий, а затем файл YAML в этом репозитории. Репозиторий, в котором присутствует YAML-файл, называется self репозиторием. По умолчанию это репозиторий, который выполняет сборки конвейера.

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

Конвейеры YAML недоступны в TFS.

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

Триггеры CI

Триггеры непрерывной интеграции (CI) приводят к запуску конвейера при отправке обновления в указанные ветви или при отправке указанных тегов.

Конвейеры YAML настраиваются по умолчанию с помощью триггера CI во всех ветвях.

Ветви

Вы можете управлять тем, какие ветви получают триггеры CI, с помощью простого синтаксиса:

trigger:
- main
- releases/*

Можно указать полное имя ветви (например, main) или подстановочный знак (например, releases/*). Дополнительные сведения о синтаксисе подстановочных знаков см. в разделе Подстановочные знаки.

Примечание

Нельзя использовать переменные в триггерах, так как переменные оцениваются во время выполнения (после срабатывания триггера).

Примечание

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

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

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

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

Если указать exclude предложение без include предложения, оно эквивалентно указанию * в предложении include .

Помимо указания имен ветвей в branches списках, можно также настроить триггеры на основе тегов в следующем формате:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Если триггеры не указаны, значение по умолчанию будет таким, как если бы вы написали:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Важно!

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

Пакетная обработка запусков CI

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

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

Примечание

batch не поддерживается в триггерах ресурсов репозитория.

Чтобы уточнить этот пример, предположим, что отправка A в main вызвала выполнение приведенного выше конвейера. Во время выполнения этого конвейера в репозиторий выполняются дополнительные отправки B и C . Эти обновления не запускают новые независимые запуски сразу. Но после завершения первого запуска все отправки до этого момента времени объединяются вместе и запускается новый запуск.

Примечание

Если конвейер содержит несколько заданий и этапов, то первый запуск по-прежнему должен достичь конечного состояния, завершив или пропустив все свои задания и этапы, прежде чем начнется второй запуск. По этой причине необходимо соблюдать осторожность при использовании этой функции в конвейере с несколькими этапами или утверждениями. Если в таких случаях вы хотите выполнить пакетную обработку сборок, рекомендуется разделить процесс CI/CD на два конвейера: один для сборки (с пакетной обработкой) и один для развертываний.

Пути

Можно указать пути к файлам для включения или исключения.

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

При указании путей необходимо явно указать ветви для активации, если используется Azure DevOps Server 2019.1 или более поздней версии. Вы не можете активировать конвейер только с фильтром пути; Необходимо также иметь фильтр ветви, а измененные файлы, соответствующие фильтру пути, должны относиться к ветви, соответствующей фильтру ветвей. Если вы используете Azure DevOps Server 2020 или более поздней версии, можно опустить branches фильтрацию по всем ветвям в сочетании с фильтром пути.

Подстановочные карточки поддерживаются для фильтров путей. Например, можно включить все пути, соответствующие src/app/**/myapp*. При указании фильтров пути можно использовать дикие символы карта (**, *или ?) ).

  • Пути всегда указываются относительно корневого каталога репозитория.
  • Если фильтры путей не заданы, корневая папка репозитория будет включена неявно по умолчанию.
  • Если вы исключите путь, вы также не сможете включить его, пока не укажете его в более глубокой папке. Например, если исключить /tools, можно включить /tools/trigger-runs-on-these.
  • Порядок фильтров пути не имеет значения.
  • В путях в Git учитывается регистр. Обязательно используйте тот же вариант, что и для реальных папок.
  • Нельзя использовать переменные в путях, так как переменные вычисляются во время выполнения (после срабатывания триггера).

Теги

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

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

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

Важно!

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

Отказ от CI

Отключение триггера CI

Вы можете полностью отказаться от триггеров CI, указав trigger: none.

# A pipeline with no CI trigger
trigger: none

Важно!

При отправке изменения в ветвь файл YAML в этой ветви оценивается, чтобы определить, следует ли запускать ci-код.

Конвейеры YAML недоступны в TFS.

Пропуск CI для отдельных push-уведомлений

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

Вы также можете указать Azure Pipelines пропустить запуск конвейера, который обычно активируется при отправке. Просто включите [skip ci] в сообщение или описание любой из фиксаций, которые являются частью отправки, и Azure Pipelines пропустит выполнение CI для этой отправки. Можно также использовать любой из следующих вариантов.

  • [skip ci] или [ci skip]
  • skip-checks: true или skip-checks:true
  • [skip azurepipelines] или [azurepipelines skip]
  • [skip azpipelines] или [azpipelines skip]
  • [skip azp] или [azp skip]
  • ***NO_CI***

Использование типа триггера в условиях

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

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Поведение триггеров при создании новых ветвей

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

Ниже описано поведение при отправке новой ветви (которая соответствует фильтрам ветви) в репозиторий:

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

подстановочные знаки;

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

  • Если вы запускаете шаблон с * в конвейере YAML, необходимо заключит шаблон в кавычки, например "*-releases".
  • Для ветвей и тегов:
    • Подстановочный знак может отображаться в любом месте шаблона.
  • Для путей:
    • В Azure DevOps Server 2022 и более поздних версиях, включая Azure DevOps Services, подстановочный знак может отображаться в любом месте шаблона пути, и вы можете использовать * или ?.
    • В Azure DevOps Server 2020 и более низких версиях вы можете включить * в качестве конечного символа, но он не делает ничего другого, чем указание имени каталога само по себе. Вы можете не включать * в середину фильтра пути и не использовать ?.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Триггеры запроса на вытягивание

Триггеры запроса на вытягивание (PR) приводят к запуску конвейера при каждом открытии запроса на вытягивание или при отправке изменений в него. В Azure Repos Git эта функция реализуется с помощью политик ветвей. Чтобы включить проверку запроса на вытягивание, перейдите к политикам ветви для нужной ветви и настройте политику проверки сборки для этой ветви. Дополнительные сведения см. в разделе Настройка политик ветвей.

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

  • Конвейеры, заданные политикой проверки сборки целевой ветви, будут выполняться при фиксации слияния (объединенном коде между исходной и целевой ветвями запроса на вытягивание), независимо от того, существуют ли отправленные фиксации, сообщения или описания которых содержатся [skip ci] (или любой из их вариантов).
  • Конвейеры, активированные изменениями в исходной ветви запроса на вытягивание, если нет отправленных фиксаций, содержащих сообщения или описания [skip ci] (или любые из их вариантов). Если хотя бы одна отправленная фиксация содержит [skip ci], конвейеры не будут выполняться.

Наконец, после слияния запроса на вытягивание Azure Pipelines запустит конвейеры CI, активированные принудительной отправкой в целевую ветвь, даже если некоторые сообщения или описания объединенных фиксаций содержат [skip ci] (или любой из их вариантов).

Примечание

Чтобы настроить сборки проверки для репозитория Azure Repos Git, необходимо быть администратором проекта.

Примечание

Черновики запросов на вытягивание не активируют конвейер, даже если настроена политика ветви.

Проверка вкладов из вилок

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

Ограничение область авторизации задания

Azure Pipelines предоставляет несколько параметров безопасности для настройки область авторизации задания, с которыми выполняются конвейеры.

Ограничение область авторизации задания текущим проектом

Azure Pipelines предоставляет два область ограничить авторизацию задания текущими параметрами проекта:

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

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

Если репозиторий Azure Repos Git находится в проекте, отличном от проекта конвейера, и параметр Ограничить авторизацию задания область для типа конвейера включен, необходимо предоставить разрешение на удостоверение службы сборки для конвейера для второго проекта. Дополнительные сведения см. в статье Управление разрешениями учетной записи службы сборки.

Azure Pipelines предоставляет параметр безопасности для настройки область авторизации задания, с которым выполняются конвейеры.

  • Ограничить область авторизации заданий текущим проектом. Этот параметр применяется к конвейерам YAML и классическим конвейерам сборки. Этот параметр не применяется к классическим конвейерам выпуска.

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

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

Дополнительные сведения об ограничении область авторизации заданий см. в статье Общие сведения о маркерах доступа к заданиям.

Ограничение область авторизации заданий для указанных репозиториев Azure DevOps

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

Чтобы настроить этот параметр, перейдите в раздел Конвейеры, Параметры в разделе Параметры организации или Параметры проекта. Если параметр включен на уровне организации, параметр неактивен и недоступен на уровне параметров проекта.

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

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

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

Например, если параметр Ограничить авторизацию заданий область для указанных репозиториев Azure DevOps включен, если конвейер находится в FabrikamProject/Fabrikam репозитории в вашей организации и вы хотите использовать скрипт для проверка FabrikamProject/FabrikamTools репозитория, необходимо ссылаться на этот репозиторий checkout на шаге или с помощью инструкции uses .

Если вы уже извлекаете репозиторий FabrikamTools в конвейере с помощью шага оформления заказа, вы можете впоследствии использовать скрипты для взаимодействия с этим репозиторием.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

Примечание

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

Защита доступа к репозиториям в конвейерах YAML

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

Чтобы настроить этот параметр, перейдите в раздел Конвейеры, Параметры в разделе Параметры организации или Параметры проекта. Если параметр включен на уровне организации, параметр неактивен и недоступен на уровне параметров проекта.

Важно!

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

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

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

Например, если включена защита доступа к репозиториям в конвейерах YAML, если конвейер находится в FabrikamProject/Fabrikam репозитории в вашей организации и вы хотите использовать скрипт для проверка FabrikamProject/FabrikamTools репозитория, необходимо ссылаться на этот репозиторий checkout на шаге или с помощью инструкции uses .

Если вы уже извлекаете репозиторий FabrikamTools в конвейере с помощью шага оформления заказа, вы можете впоследствии использовать скрипты для взаимодействия с этим репозиторием.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Примечание

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

Извлечение

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

Примечание

При включении шага оформления заказа в конвейер мы выполняем следующую команду: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Если это не соответствует вашим потребностям, можно исключить встроенную функцию оформления заказа checkout: none , а затем использовать задачу скрипта для выполнения собственного оформления заказа.

Предпочтительная версия Git

Агент Windows поставляется с собственной копией Git. Если вы предпочитаете предоставлять собственный Git, а не использовать включенную копию, задайте для значение System.PreferGitFromPathtrue. Этот параметр всегда имеет значение true для агентов, отличных от Windows.

Путь оформления заказа

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

Этот параметр можно настроить path на шаге Извлечение конвейера.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Подмодули

Этот параметр можно настроить submodules на шаге Извлечение конвейера, если вы хотите скачивать файлы из подмодулей.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

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

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

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

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

    • Добавляется с помощью URL-адреса относительно репозитория main. Например.

      • Это будет извлечено: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        В этом примере подмодуль ссылается на репозиторий (FabrikamFiber) в той же организации Azure DevOps, но в другом проекте (FabrikamFiberProject). Те же учетные данные, которые используются агентом для получения источников из репозитория main, также используются для получения источников для подмодулей. Для этого маркер доступа задания должен иметь доступ к репозиторию во втором проекте. Если вы ограничили маркер доступа к заданию, как описано в разделе выше, вы не сможете это сделать. Вы можете разрешить маркеру доступа задания доступ к репозиторию во втором проекте, (а) явно предоставив доступ к учетной записи службы сборки проекта во втором проекте или (б) используя маркеры доступа на уровне коллекции вместо маркеров уровня проекта для всей организации. Дополнительные сведения об этих параметрах и их последствиях для безопасности см. в статье Доступ к репозиториям, артефактам и другим ресурсам.

      • Этот из них не будет извлечен: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

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

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

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

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

Обязательно замените "<BASE64_ENCODED_STRING>" строкой pat:token в кодировке Base64.

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

Примечание

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

Синхронизация тегов

Шаг извлечения использует --tags параметр при выборе содержимого репозитория Git. Это приводит к тому, что сервер будет получить все теги, а также все объекты, на которые указывают эти теги. Это увеличивает время выполнения задачи в конвейере, особенно при наличии большого репозитория с несколькими тегами. Кроме того, шаг оформления заказа синхронизирует теги даже при включении параметра неглубокой выборки, что может помешать его назначению. Чтобы уменьшить объем данных, извлекаемых или извлекаемых из репозитория Git, корпорация Майкрософт добавила новую возможность оформления заказа для управления поведением синхронизации тегов. Этот параметр доступен как в классическом конвейере, так и в конвейерах YAML.

Можно ли синхронизировать теги при извлечении репозитория, можно настроить в YAML, задав fetchTags свойство и в пользовательском интерфейсе, настроив параметр Синхронизация тегов .

Этот параметр можно настроить fetchTags на шаге Извлечение конвейера.

Чтобы настроить параметр в YAML, задайте fetchTags свойство .

steps:
- checkout: self
  fetchTags: true

Этот параметр также можно настроить с помощью параметра Синхронизация тегов в пользовательском интерфейсе параметров конвейера.

  1. Измените конвейер YAML и выберите Дополнительные действия, Триггеры.

    Снимок экрана: меню

  2. Выберите YAML, Получить источники.

    Снимок экрана: получение источников.

  3. Настройте параметр Синхронизация тегов .

    Снимок экрана: параметр синхронизации тегов.

Примечание

Если вы явно задали fetchTags на шаге checkout , этот параметр имеет приоритет над параметром, настроенным в пользовательском интерфейсе параметров конвейера.

Поведение по умолчанию

  • Для существующих конвейеров, созданных до выпуска спринта Azure DevOps 209, выпущенного в сентябре 2022 г., значение по умолчанию для синхронизации тегов остается таким же, как и существующее поведение до добавления параметров синхронизации тегов , то есть true.
  • Для новых конвейеров, созданных после выпуска 209 спринта Azure DevOps, по умолчанию для синхронизации тегов используется falseзначение .

Примечание

Если вы явно задали fetchTags на шаге checkout , этот параметр имеет приоритет над параметром, настроенным в пользовательском интерфейсе параметров конвейера.

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

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

Важно!

Для новых конвейеров, созданных после обновления azure DevOps sprint 209 за сентябрь 2022 г., по умолчанию включена неполная выборка и настроена глубина 1. Ранее по умолчанию не использовалось мелкое получение. Чтобы проверка конвейера, просмотрите параметр Поверхностная выборка в пользовательском интерфейсе параметров конвейера, как описано в следующем разделе.

Этот параметр можно настроить fetchDepth на шаге Извлечение конвейера.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

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

  1. Измените конвейер YAML и выберите Дополнительные действия, Триггеры.

    Снимок экрана: меню

  2. Выберите YAML, Получить источники.

    Снимок экрана: получение источников.

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

    Снимок экрана: параметры.

Примечание

Если вы явно задали fetchDepth на шаге checkout , этот параметр имеет приоритет над параметром, настроенным в пользовательском интерфейсе параметров конвейера. Параметр fetchDepth: 0 получает весь журнал и переопределяет параметр Поверхностная выборка .

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

Примечание

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

Не синхронизировать источники

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

  • Инициализация, настройка и выборка Git с помощью собственных настраиваемых параметров.

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

Вы можете настроить параметр Не синхронизировать источники на шаге Извлечение конвейера, задав .checkout: none

steps:
- checkout: none  # Don't sync sources

Примечание

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

Чистая сборка

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

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

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

Примечание

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

Этот параметр можно настроить clean на шаге Извлечение конвейера.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

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

git clean -ffdx
git reset --hard HEAD

Для получения дополнительных параметров можно настроить workspace параметр задания.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Это дает следующие параметры очистки.

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

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

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

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

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

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

Настройка параметров Git в YAML.

В классическом редакторе выберите YAML, выберите задачу Получить источники и настройте нужные свойства.

В классическом редакторе выберите YAML > Получить источники.

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

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

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

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

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

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

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

Проблемы, связанные с интеграцией Azure Repos, делятся на три категории:

  • Триггеры сбоя: Мой конвейер не активируется при отправке обновления в репозиторий.
  • Сбой оформления заказа: Мой конвейер активируется, но на шаге оформления происходит сбой.
  • Неправильная версия: Мой конвейер выполняется, но в нем используется непредвиденная версия источника или YAML.

Триггеры сбоя

Я только что создал новый конвейер YAML с триггерами CI/PR, но конвейер не запускается.

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

  • Переопределяются ли триггеры YAML CI или PR параметрами конвейера в пользовательском интерфейсе? При редактировании конвейера выберите ... , а затем — Триггеры.

    Пользовательский интерфейс параметров конвейера.

    Проверьте параметр Переопределить триггер YAML отсюда для типов триггера (непрерывная интеграция или проверка запроса на вытягивание), доступных для вашего репозитория.

    Переопределите триггер YAML отсюда.

  • Вы настраиваете триггер запроса на вытягивание в YAML-файле или в политиках ветвей для репозитория? Для репозитория Azure Repos Git невозможно настроить триггер запроса на вытягивание в YAML-файле. Необходимо использовать политики ветвей.

  • Ваш конвейер приостановлен или отключен? Откройте редактор конвейера и выберите Параметры, чтобы проверка. Если конвейер приостановлен или отключен, триггеры не работают.

  • Вы обновили YAML-файл в правильной ветви? Если вы отправляете обновление в ветвь, то YAML-файл в той же ветви управляет поведением CI. Если вы отправляете обновление в исходную ветвь, то YAML-файл, полученный в результате слияния исходной ветви с целевой ветвью, управляет поведением запроса на вытягивание. Убедитесь, что ФАЙЛ YAML в правильной ветви имеет необходимую конфигурацию CI или PR.

  • Правильно ли вы настроили триггер? При определении триггера YAML можно указать предложения include и exclude для ветвей, тегов и путей. Убедитесь, что предложение include соответствует сведениям о фиксации и что предложение exclude не исключает их. Проверьте синтаксис триггеров и убедитесь, что он является точным.

  • Использовались ли переменные при определении триггера или путей? Это не поддерживается.

  • Вы использовали шаблоны для файла YAML? Если да, убедитесь, что триггеры определены в файле YAML main. Триггеры, определенные в файлах шаблонов, не поддерживаются.

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

  • Вы только что принудили новую ветвь? Если это так, новая ветвь может не начать новое выполнение. См. раздел Поведение триггеров при создании новых ветвей.

Мои триггеры CI или PR работали нормально. Но они перестали работать сейчас.

Сначала выполните действия по устранению неполадок, описанные в предыдущем вопросе. Затем выполните следующие дополнительные действия.

  • У вас есть конфликты слияния в запросе на вытягивание? Для запроса на вытягивание, который не активировал конвейер, откройте его и проверка, имеет ли он конфликт слияния. Разрешите конфликт слияния.

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

Я не хочу, чтобы пользователи переопределяли список ветвей для триггеров при обновлении файла YAML. Как это сделать?

Пользователи с разрешениями на участие в коде могут обновить ФАЙЛ YAML и включить или исключить дополнительные ветви. В результате пользователи могут включить собственный компонент или ветвь пользователя в файл YAML и отправить это обновление в компонент или в ветвь пользователя. Это может привести к активации конвейера для всех обновлений этой ветви. Если вы хотите предотвратить такое поведение, вы можете:

  1. Измените конвейер в пользовательском интерфейсе Azure Pipelines.
  2. Перейдите в меню Триггеры .
  3. Выберите Переопределить триггер непрерывной интеграции YAML отсюда.
  4. Укажите ветви для включения или исключения для триггера.

При выполнении этих действий все триггеры CI, указанные в файле YAML, игнорируются.

В конвейере YAML есть несколько репозиториев. Разделы справки настроить триггеры для каждого репозитория?

См. триггеры в разделе Использование нескольких репозиториев.

Сбой оформления заказа

На этапе оформления я вижу следующую ошибку в файле журнала. Как ее исправить?

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

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

  • Репозиторий по-прежнему существует? Сначала убедитесь, что это делается, открыв его на странице Репозитории .

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

  • Что такое область авторизации задания конвейера?

    • Если область является коллекцией:

      • Это может быть прерывистая ошибка. Повторно запустите конвейер.
      • Возможно, кто-то удалил доступ к учетной записи службы сборки коллекции Project.
        • Перейдите в раздел Параметры проекта для проекта, в котором существует репозиторий. Выберите Репозитории > Репозитории > , определенный репозиторий, а затем — Безопасность.
        • Проверьте, существует ли в списке пользователей служба сборки коллекции проектов (имя коллекции ).
        • Убедитесь, что у этой учетной записи есть тег Create и доступ на чтение .

    • Если область является проектом:

      • Находится ли репозиторий в том же проекте, что и конвейер?
        • Да:
          • Это может быть прерывистая ошибка. Повторно запустите конвейер.
          • Возможно, кто-то удалил доступ к учетной записи службы сборки Project.
            • Перейдите в раздел Параметры проекта для проекта, в котором существует репозиторий. Выберите Репозитории > Репозитории > конкретный репозиторий, а затем — Безопасность.
            • Проверьте, существует ли служба сборки с именем проекта (имя коллекции) в списке пользователей.
            • Проверьте, есть ли у этой учетной записи тег Create и доступ на чтение .
        • Нет:

Неправильная версия

В конвейере используется неправильная версия файла YAML. Почему?

  • Для триггеров CI файл YAML, который находится в отталкиваемой ветви, оценивается, чтобы определить, следует ли выполнять сборку CI.
  • Для триггеров запроса на вытягивание оценивается файл YAML, полученный в результате слияния исходной и целевой ветвей запроса на вытягивание, чтобы определить, следует ли выполнять сборку запроса на вытягивание.