Поделиться через

Сборка репозиториев Bitbucket Cloud

  • Статья

Azure DevOps Services

Azure Pipelines может автоматически создавать и проверять каждый запрос на вытягивание и зафиксировать его в репозитории Bitbucket Cloud. В этой статье описывается настройка интеграции между Bitbucket Cloud и Azure Pipelines.

Bitbucket и Azure Pipelines — это две независимые службы, которые хорошо интегрируются вместе. Пользователи Bitbucket Cloud не получают автоматически доступ к Azure Pipelines. Их необходимо добавить явным образом в Azure Pipelines.

Получение доступа к репозиториям Bitbucket

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

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

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

Существует 2 типа проверки подлинности для предоставления Azure Pipelines доступа к репозиториям Bitbucket Cloud при создании конвейера.

Тип аутентификации Запуск конвейеров с помощью
1. OAuth Ваше личное удостоверение Bitbucket
2. Имя пользователя и пароль Ваше личное удостоверение Bitbucket

Аутентификация OAuth

OAuth — это самый простой тип проверки подлинности для начала работы с репозиториями в учетной записи Bitbucket. Обновления состояния Bitbucket будут выполняться от имени личных удостоверений Bitbucket. Чтобы конвейеры работали, доступ к репозиторию должен оставаться активным.

Чтобы использовать OAuth, войдите в Bitbucket при появлении запроса во время создания конвейера. Затем нажмите кнопку "Авторизовать ", чтобы авторизовать с помощью OAuth. Подключение OAuth будет сохранено в проекте Azure DevOps для последующего использования, а также используется в создаваемом конвейере.

Примечание.

Максимальное количество репозиториев Bitbucket, которое может загружать пользовательский интерфейс Azure DevOps Services, составляет 2000.

Проверка пароля

Сборки и обновления состояния Bitbucket будут выполняться от имени вашего личного удостоверения. Для поддержания работы сборок доступ к репозиторию должен оставаться активным.

Чтобы создать подключение к паролю, посетите подключения службы в параметрах проекта Azure DevOps. Создайте подключение службы Bitbucket и укажите имя пользователя и пароль для подключения к репозиторию Bitbucket Cloud.

Триггеры 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 пакетной обработки

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

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

Примечание.

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

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

Примечание.

Для репозиториев Bitbucket Cloud используется branches единственный способ указать триггеры тегов. Синтаксис tags: не поддерживается для Bitbucket.

Отказ от CI

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

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

# A pipeline with no CI trigger
trigger: none

Важно!

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

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

Ветви

Вы можете указать целевые ветви при проверке запросов на вытягивание. Например, чтобы проверить запросы на вытягивание, предназначенные для этого объекта master , releases/*можно использовать следующий pr триггер.

pr:
- main
- releases/*

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

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

Примечание.

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

Примечание.

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

Каждый новый запуск создает последнюю фиксацию из исходной ветви запроса на вытягивание. Это отличается от того, как Azure Pipelines создает запросы на вытягивание в других репозиториях (например, Azure Repos или GitHub), где он создает фиксацию слияния. К сожалению, Bitbucket не предоставляет информацию о фиксации слияния, которая содержит объединенный код между исходным и целевыми ветвями запроса на вытягивание.

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

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

Важно!

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

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

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

Пути

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

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

Совет.

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

Несколько обновлений pr

Можно указать, должны ли дополнительные обновления для pr отменить выполняемые проверки для одного и того же PR. Значение по умолчанию — true.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

Отказ от проверки pr

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

# no PR triggers
pr: none

Дополнительные сведения см. в разделе "Триггер pr" в схеме YAML.

Примечание.

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

Информационные запуски

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

Информационный запуск выглядит на следующем снимке экрана.

Screenshot of an informational pipeline run.

Вы можете распознать информационный запуск следующими атрибутами:

  • Состояние Canceled
  • Длительность составляет < 1s
  • Имя выполнения содержит один из следующих текстов:
    • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
    • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
    • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
    • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
  • Имя запуска обычно содержит ошибку BitBucket / GitHub, которая привела к сбою загрузки конвейера YAML
  • Нет этапов/ заданий и шагов

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

Ограничения

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

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

Проблемы, связанные с интеграцией Bitbucket, попадают в следующие категории:

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

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

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

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

  • Веб-перехватчики используются для обмена обновлениями из Bitbucket с Azure Pipelines. В Bitbucket перейдите к параметрам репозитория, а затем к веб-перехватчикам. Убедитесь, что существуют веб-перехватчики.

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

  • Вы обновили файл 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. Почему так?

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