Создание репозиториев Azure Repos Git или TFS Git

  • Статья

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

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

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

Создайте новый конвейер, сначала выбрав репозиторий, а затем файл YAML в этом репозитории. Репозиторий, в котором присутствует ФАЙЛ YAML, называется self репозиторием. По умолчанию это репозиторий, который выполняет сборки конвейера.

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

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

Триггеры CI

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

Конвейеры YAML настраиваются по умолчанию с триггером CI во всех ветвях, если не включен параметр триггера YAML CI, представленный в спринте Azure DevOps 227. Параметр триггера CI disable отключается на уровне организации или на уровне проекта. Если включен параметр триггера CI отключать подразумеваемый параметр YAML, триггеры CI для конвейеров YAML не включены, если конвейер YAML не содержит trigger раздел. По умолчанию отключена подразумеваемая активация CI YAML.

Ветви

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

trigger:
- main
- releases/*

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

Примечание.

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

Примечание.

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

Для более сложных триггеров, использующих 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}

Если вы не указали какие-либо триггеры, а параметр триггера YAML CI disable не включен, по умолчанию используется значение по умолчанию, как если бы вы написали:

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 не поддерживается в триггерах ресурсов репозитория.

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

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

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

Теги

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

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

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

Внимание

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

Отказ от CI

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

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

# A pipeline with no CI trigger
trigger: none

Внимание

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

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

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

Вы также можете сообщить Azure Pipelines пропустить запуск конвейера, что push-отправка обычно активируется. Просто включите [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. Например, добавьте следующее условие к шагу, заданию или этапу, чтобы исключить его из проверок pr.

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

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

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

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

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

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

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

  • Если вы начинаете шаблон с * конвейера 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

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

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

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

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

Примечание.

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

Примечание.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, которые вы хотите использовать в конвейере в качестве шага проверка out в задании, использующем репозиторий. Вы не сможете получить код с помощью задач сценариев и команд Git для репозитория Azure Repos Git, если только этот репозиторий не будет указан явным образом.

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

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

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

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

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

Примечание.

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

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

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

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

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

Параметр можно настроить 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 до тех пор, пока они:

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

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

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

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

      • Этот будет проверка из:git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

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

      • Этот не будет проверка выходить:git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

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

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

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

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

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

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

Примечание.

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

Теги синхронизации

Внимание

Функция тегов синхронизации поддерживается в Azure Repos Git с Azure DevOps Server 2022.1 и выше.

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

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

Параметр можно настроить fetchTags на шаге выхода конвейера.

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

steps:
- checkout: self
  fetchTags: true

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

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

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

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

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

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

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

Примечание.

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

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

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

Примечание.

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

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

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

Внимание

Новые конвейеры, созданные после обновления Azure DevOps за сентябрь 2022 г. спринтом 209 г., включают неглубокое получение по умолчанию и настроены с глубиной 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, Get sources(Получить источники).

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

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

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

Примечание.

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

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

Примечание.

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

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

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

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

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

Вы можете настроить параметр "Не синхронизировать источники " на шаге выхода конвейера, задав параметр 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

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

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

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

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

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

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

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

Настройте параметры Git, YAML.

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

В классическом редакторе выберите yamL > Get sources.

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

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

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

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

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

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

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

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

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

Сбой триггеров

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сбой проверка out

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

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

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

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

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

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

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

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

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

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

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

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

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