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

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

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

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 во всех ветвях, если параметр Отключить подразумеваемый триггер CI YAML, представленный в спринте Azure DevOps 227, включен. Параметр Отключить подразумеваемый триггер CI YAML можно настроить на уровне организации или на уровне проекта. Если параметр Отключить подразумеваемый триггер CI YAML включен, триггеры CI для конвейеров YAML не включены, если конвейер YAML не имеет trigger раздела. По умолчанию Отключить подразумеваемый триггер CI YAML не включен.

Ветви

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

trigger:
- main
- releases/*

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

Примечание.

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

Примечание.

Если вы используете шаблоны для создания файлов 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}

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

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

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

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

  • Пути всегда указываются относительно корневого каталога репозитория.
  • Если фильтры путей не заданы, корневая папка репозитория неявно включена по умолчанию.
  • Если вы исключите путь, вы также не можете включить его, если вы не квалифицируйте его в более глубокую папку. Например, если исключить /tools, можно включить /tools/trigger-runs-on-on-эти
  • Порядок фильтров путей не имеет значения.
  • Пути в 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, а другой — при отправке обновления в код приложения. В этих случаях необходимо понять, как конвейеры активируются при создании новой ветви.

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

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

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

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

  • Если вы запускаете шаблон с * в конвейере 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 не предоставляет информацию о фиксации слияния, которая содержит объединенный код между исходным и целевыми ветвями запроса на вытягивание.

Если в файле YAML не отображаются триггеры pr, проверки запросов на вытягивание автоматически включены для всех ветвей, как если бы вы написали следующий триггер 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-эти
  • Порядок фильтров путей не имеет значения.
  • Пути в 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 собирается запустить конвейер.

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

снимок экрана: запуск информационного конвейера.

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

  • Состояние 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, но конвейер не активируется.

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

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

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

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

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

  • Веб-перехватчики используются для обмена обновлениями из 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.