Compartir a través de

Compilación de repositorios de Bitbucket Cloud

  • Artículo

Azure DevOps Services

Azure Pipelines puede compilar y validar automáticamente todas las solicitudes de incorporación de cambios y confirmarlas en el repositorio de Bitbucket Cloud. En este artículo se describe cómo configurar la integración entre Bitbucket Cloud y Azure Pipelines.

Bitbucket y Azure Pipelines son dos servicios independientes que se integran bien. Los usuarios de Bitbucket Cloud no obtienen acceso automáticamente a Azure Pipelines. Debe agregarlos explícitamente a Azure Pipelines.

Acceso a repositorios de Bitbucket

Para crear una canalización, seleccione primero un repositorio de Bitbucket Cloud y, a continuación, un archivo YAML en ese repositorio. El repositorio en el que está presente el archivo YAML se denomina self repositorio. De forma predeterminada, este es el repositorio que compila la canalización.

Más adelante puede configurar la canalización para consultar un repositorio diferente o varios repositorios. Para obtener información sobre cómo hacerlo, consulte desprotección de varios repositorios.

Se debe conceder acceso a Azure Pipelines a los repositorios para capturar el código durante las compilaciones. Además, el usuario que configura la canalización debe tener acceso de administrador a Bitbucket, ya que esa identidad se usa para registrar un webhook en Bitbucket.

Hay dos tipos de autenticación para conceder a Azure Pipelines acceso a los repositorios de Bitbucket Cloud al crear una canalización.

Tipo de autenticación Canalizaciones que se ejecutan mediante
1. OAuth Su identidad personal de Bitbucket
2. nombre de usuario y contraseña Su identidad personal de Bitbucket

Autenticación OAuth

OAuth es el tipo de autenticación más sencillo para empezar a trabajar con los repositorios de la cuenta de Bitbucket. Las actualizaciones de estado de Bitbucket se realizarán en nombre de su identidad personal de Bitbucket. Para que las canalizaciones sigan funcionando, el acceso al repositorio debe permanecer activo.

Para usar OAuth, inicie sesión en Bitbucket cuando se le solicite durante la creación de la canalización. A continuación, haga clic en Autorizar para autorizar con OAuth. Una conexión de OAuth se guardará en el proyecto de Azure DevOps para su uso posterior, así como en la canalización que se va a crear.

Nota:

El número máximo de repositorios de Bitbucket que la interfaz de usuario de Azure DevOps Services puede cargar es de 2000.

Autenticación de contraseña

Las compilaciones y las actualizaciones de estado de Bitbucket se realizarán en nombre de su identidad personal. Para que las compilaciones sigan funcionando, el acceso al repositorio debe permanecer activo.

Para crear una conexión de contraseña, visite Conexiones de servicio en la configuración del proyecto de Azure DevOps. Cree una nueva conexión de servicio de Bitbucket y proporcione el nombre de usuario y la contraseña para conectarse al repositorio de Bitbucket Cloud.

Desencadenadores de CI

Los desencadenadores de integración continua (CI) hacen que una canalización se ejecute siempre que inserte una actualización en las ramas especificadas o inserte etiquetas especificadas.

Las canalizaciones de YAML se configuran de forma predeterminada con un desencadenador de CI en todas las ramas, a menos que la configuración de de desencadenador de CI de YAML implícito, introducida en sprint de Azure DevOps 227, esté habilitada. El deshabilitar el desencadenador de CI de YAML implícito se puede configurar en el nivel de organización o en el nivel de proyecto. Cuando el Deshabilitar el desencadenador de CI de YAML implícito está habilitado, los desencadenadores de CI para canalizaciones YAML no están habilitados si la canalización yaML no tiene una sección de trigger. De forma predeterminada, deshabilitar el desencadenador de CI de YAML implícito no está habilitado.

Ramas

Puede controlar qué ramas obtienen desencadenadores de CI con una sintaxis simple:

trigger:
- main
- releases/*

Puede especificar el nombre completo de la rama (por ejemplo, main) o un carácter comodín (por ejemplo, releases/*). Consulte caracteres comodín para obtener información sobre la sintaxis de caracteres comodín.

Nota:

No puede usar variables en desencadenadores, ya que las variables se evalúan en tiempo de ejecución (después de que se haya desencadenado el desencadenador).

Nota:

Si usa plantillas de para crear archivos YAML, solo puede especificar desencadenadores en el archivo YAML principal para la canalización. No se pueden especificar desencadenadores en los archivos de plantilla.

Para desencadenadores más complejos que usan exclude o batch, debe usar la sintaxis completa como se muestra en el ejemplo siguiente.

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

En el ejemplo anterior, la canalización se desencadenará si se inserta un cambio en main o en cualquier rama de versiones. Sin embargo, no se desencadenará si se realiza un cambio en una rama de versiones que comienza con old.

Si especifica una cláusula exclude sin una cláusula include, equivale a especificar * en la cláusula include.

Además de especificar nombres de rama en las listas de branches, también puede configurar desencadenadores basados en etiquetas mediante el siguiente formato:

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

Si no especificó ningún desencadenador y el Deshabilitar el desencadenador implícito de CI de YAML configuración no está habilitado, el valor predeterminado es como si escribiera:

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

Importante

Cuando se especifica un desencadenador, reemplaza el desencadenador implícito predeterminado y solo se insertan en ramas configuradas explícitamente para que se incluyan desencadenará una canalización. Las inclusión se procesan primero y, a continuación, se quitan de esa lista.

Ejecuciones de CI de procesamiento por lotes

Si tiene muchos miembros del equipo que cargan cambios a menudo, puede que desee reducir el número de ejecuciones que se inician. Si establece batch en true, cuando se ejecuta una canalización, el sistema espera hasta que se completa la ejecución y, a continuación, inicia otra ejecución con todos los cambios que aún no se han compilado.

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

Nota:

batch no se admite en desencadenadores de recursos de repositorio.

Para aclarar este ejemplo, supongamos que una A de inserción para main hizo que se ejecutara la canalización anterior. Mientras se ejecuta esa canalización, se B y C se producen inserciones adicionales en el repositorio. Estas actualizaciones no inician nuevas ejecuciones independientes inmediatamente. Pero una vez completada la primera ejecución, todas las inserciones hasta ese momento de tiempo se agrupan por lotes y se inicia una nueva ejecución.

Nota:

Si la canalización tiene varios trabajos y fases, la primera ejecución todavía debe alcanzar un estado de terminal completando o omitiendo todos sus trabajos y fases antes de que se pueda iniciar la segunda ejecución. Por este motivo, debe tener precaución al usar esta característica en una canalización con varias fases o aprobaciones. Si desea procesar por lotes las compilaciones en tales casos, se recomienda dividir el proceso de CI/CD en dos canalizaciones: una para la compilación (con procesamiento por lotes) y otra para las implementaciones.

Rutas de acceso

Puede especificar rutas de acceso de archivo para incluir o excluir.

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

Al especificar rutas de acceso, debe especificar explícitamente ramas en las que se desencadenará si usa Azure DevOps Server 2019.1 o versiones posteriores. No se puede desencadenar una canalización solo con un filtro de ruta de acceso; También debe tener un filtro de rama y los archivos modificados que coincidan con el filtro de ruta de acceso deben ser de una rama que coincida con el filtro de rama. Si usa Azure DevOps Server 2020 o versiones posteriores, puede omitir branches filtrar en todas las ramas junto con el filtro de ruta de acceso.

Los caracteres comodín se admiten para los filtros de ruta de acceso. Por ejemplo, puede incluir todas las rutas de acceso que coincidan con src/app/**/myapp*. Puede usar caracteres comodín (**, *o ?) al especificar filtros de ruta de acceso.

  • Las rutas de acceso siempre se especifican en relación con la raíz del repositorio.
  • Si no establece filtros de ruta de acceso, la carpeta raíz del repositorio se incluye implícitamente de forma predeterminada.
  • Si excluye una ruta de acceso, tampoco puede incluirla a menos que la califique en una carpeta más profunda. Por ejemplo, si excluye /tools, podría incluir /tools/trigger-runs-on-these
  • El orden de los filtros de ruta de acceso no importa.
  • Las rutas de acceso de git distinguen mayúsculas de minúsculas. Asegúrese de usar el mismo caso que las carpetas reales.
  • No puede usar variables en las rutas de acceso, ya que las variables se evalúan en tiempo de ejecución (después de que se haya desencadenado el desencadenador).

Nota:

En el caso de los repositorios de Bitbucket Cloud, el uso de branches sintaxis es la única manera de especificar desencadenadores de etiquetas. La sintaxis tags: no se admite para Bitbucket.

No participar en CI

Deshabilitación del desencadenador de CI

Puede rechazar completamente los desencadenadores de CI especificando trigger: none.

# A pipeline with no CI trigger
trigger: none

Importante

Al insertar un cambio en una rama, el archivo YAML de esa rama se evalúa para determinar si se debe iniciar una ejecución de CI.

Omisión de CI para confirmaciones individuales

También puede indicar a Azure Pipelines que omita la ejecución de una canalización que normalmente desencadenaría una inserción. Solo tiene que incluir [skip ci] en el mensaje o la descripción de cualquiera de las confirmaciones que forman parte de una inserción y Azure Pipelines omitirá la ejecución de CI para esta inserción. También puede usar cualquiera de las siguientes variaciones.

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

Uso del tipo de desencadenador en condiciones

Es un escenario común ejecutar diferentes pasos, trabajos o fases en la canalización en función del tipo de desencadenador que inició la ejecución. Puede hacerlo mediante la variable del sistema Build.Reason. Por ejemplo, agregue la siguiente condición al paso, el trabajo o la fase para excluirla de las validaciones de PR.

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

Comportamiento de desencadenadores cuando se insertan nuevas ramas

Es habitual configurar varias canalizaciones para el mismo repositorio. Por ejemplo, puede tener una canalización para compilar los documentos de la aplicación y otro para compilar el código fuente. Puede configurar desencadenadores de CI con filtros de rama y filtros de ruta de acceso adecuados en cada una de estas canalizaciones. Por ejemplo, puede que desee que una canalización se desencadene al insertar una actualización en la carpeta docs y otra que se desencadene al insertar una actualización en el código de la aplicación. En estos casos, debe comprender cómo se desencadenan las canalizaciones cuando se crea una nueva rama.

Este es el comportamiento al insertar una nueva rama (que coincide con los filtros de rama) en el repositorio:

  • Si la canalización tiene filtros de ruta de acceso, solo se desencadenará si la nueva rama tiene cambios en los archivos que coinciden con ese filtro de ruta de acceso.
  • Si la canalización no tiene filtros de ruta de acceso, se desencadenará incluso si no hay ningún cambio en la nueva rama.

Caracteres comodín

Al especificar una rama, etiqueta o ruta de acceso, puede usar un nombre exacto o un carácter comodín. Los patrones de caracteres comodín permiten que * coincidan con cero o más caracteres y ? que coincidan con un solo carácter.

  • Si inicia el patrón con * en una canalización YAML, debe ajustar el patrón entre comillas, como "*-releases".
  • Para ramas y etiquetas:
    • Un carácter comodín puede aparecer en cualquier parte del patrón.
  • Para las rutas de acceso:
    • En Azure DevOps Server 2022 y versiones posteriores, incluido Azure DevOps Services, un carácter comodín puede aparecer en cualquier lugar dentro de un patrón de ruta de acceso y puede usar * o ?.
    • En Azure DevOps Server 2020 y versiones anteriores, puede incluir * como carácter final, pero no hace nada diferente de especificar el nombre del directorio por sí mismo. Es posible que no incluya * en medio de un filtro de ruta de acceso y no use ?.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Desencadenadores de PR

Los desencadenadores de solicitud de incorporación de cambios (PR) hacen que una canalización se ejecute siempre que se abra una solicitud de incorporación de cambios con una de las ramas de destino especificadas o cuando se realicen actualizaciones en dicha solicitud de incorporación de cambios.

Ramas

Puede especificar las ramas de destino al revisar los pull requests. Por ejemplo, para validar las solicitudes de incorporación de cambios que tienen como destino master y releases/*, puede usar el siguiente desencadenador de pr.

pr:
- main
- releases/*

Esta configuración inicia una nueva ejecución la primera vez que se crea una nueva solicitud de incorporación de cambios y después de cada actualización realizada en la solicitud de incorporación de cambios.

Puede especificar el nombre completo de la rama (por ejemplo, master) o un carácter comodín (por ejemplo, releases/*).

Nota:

No puede usar variables en desencadenadores, ya que las variables se evalúan en tiempo de ejecución (después de que se haya desencadenado el desencadenador).

Nota:

Si usa plantillas de para crear archivos YAML, solo puede especificar desencadenadores en el archivo YAML principal para la canalización. No se pueden especificar desencadenadores en los archivos de plantilla.

Cada nueva ejecución compila la confirmación más reciente desde la rama de origen de la solicitud de incorporación de cambios. Esto es diferente de cómo Azure Pipelines compila solicitudes de incorporación de cambios en otros repositorios (por ejemplo, Azure Repos o GitHub), donde compila la confirmación de combinación. Desafortunadamente, Bitbucket no expone información sobre la confirmación de combinación, que contiene el código combinado entre las ramas de origen y destino de la solicitud de incorporación de cambios.

Si no aparecen desencadenadores pr en el archivo YAML, las validaciones de solicitudes de incorporación de cambios se habilitan automáticamente para todas las ramas, como si escribiera el siguiente desencadenador de pr. Esta configuración desencadena una compilación cuando se crea cualquier solicitud de incorporación de cambios y cuando las confirmaciones entran en la rama de origen de cualquier solicitud de incorporación de cambios activa.

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

Importante

Al especificar un desencadenador de pr, reemplaza el desencadenador de pr implícito predeterminado y solo se insertan en ramas configuradas explícitamente para que se incluyan desencadenará una canalización.

Para desencadenadores más complejos que necesitan excluir determinadas ramas, debe usar la sintaxis completa como se muestra en el ejemplo siguiente.

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

Rutas de acceso

Puede especificar rutas de acceso de archivo para incluir o excluir. Por ejemplo:

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

Sugerencias:

  • Las tarjetas comodín no se admiten con filtros de ruta de acceso.
  • Las rutas de acceso siempre se especifican en relación con la raíz del repositorio.
  • Si no establece filtros de ruta de acceso, la carpeta raíz del repositorio se incluye implícitamente de forma predeterminada.
  • Si excluye una ruta de acceso, tampoco puede incluirla a menos que la califique en una carpeta más profunda. Por ejemplo, si excluye /tools, podría incluir /tools/trigger-runs-on-these
  • El orden de los filtros de ruta de acceso no importa.
  • Las rutas de acceso de git distinguen mayúsculas de minúsculas. Asegúrese de usar el mismo caso que las carpetas reales.
  • No puede usar variables en las rutas de acceso, ya que las variables se evalúan en tiempo de ejecución (después de que se haya desencadenado el desencadenador).

Varias actualizaciones de solicitud de incorporación de cambios

Puede especificar si las actualizaciones adicionales de una solicitud de incorporación de cambios deben cancelar las ejecuciones de validación en curso para la misma solicitud de incorporación de cambios. El valor predeterminado es true.

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

No participar en la validación de pr

Puede no participar en la validación de solicitudes de incorporación de cambios por completo especificando pr: none.

# no PR triggers
pr: none

Para obtener más información, consulte desencadenador de pr en el esquema yaML de .

Nota:

Si el desencadenador de pr no se está activando, asegúrese de que no ha desencadenadores yaML PR invalidados en la interfaz de usuario.

Ejecuciones informativas

Una ejecución informativa indica que Azure DevOps no pudo recuperar el código fuente de una canalización de YAML. La recuperación del código fuente se produce en respuesta a eventos externos, por ejemplo, una confirmación insertada. También ocurre en respuesta a desencadenadores internos, por ejemplo, para comprobar si hay cambios en el código e iniciar una ejecución programada o no. La recuperación de código fuente puede producir un error por varias razones, con una limitación frecuente de solicitudes por parte del proveedor del repositorio git. La existencia de una ejecución informativa no significa necesariamente que Azure DevOps ejecutara la canalización.

Una ejecución informativa tiene un aspecto similar al de la captura de pantalla siguiente.

Captura de pantalla de una ejecución de canalización informativa.

Puede reconocer una ejecución informativa mediante los atributos siguientes:

  • El estado es Canceled
  • La duración es < 1s
  • El nombre de ejecución contiene uno de los textos siguientes:
    • 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.
  • El nombre de ejecución generalmente contiene el error BitBucket /GitHub que provocó un error en la carga de la canalización de YAML.
  • Sin fases/ trabajos/pasos

Obtenga más información sobre las ejecuciones informativas de .

Limitaciones

Azure Pipelines carga un máximo de 2000 ramas de un repositorio en listas desplegables de Azure Devops Portal, por ejemplo, en la rama predeterminada de para compilaciones manuales y programadas configuración, o al elegir una rama al ejecutar una canalización manualmente. Si no ve la rama deseada en la lista, escriba manualmente el nombre de la rama deseada.

Preguntas más frecuentes

Los problemas relacionados con la integración de Bitbucket se dividen en las siguientes categorías:

Desencadenadores con errores

Acabo de crear una nueva canalización de YAML con desencadenadores de CI/PR, pero la canalización no se desencadena.

Siga cada uno de estos pasos para solucionar problemas de los desencadenadores con errores:

  • ¿Se reemplazan los desencadenadores de CI o PR de YAML invalidados por la configuración de canalización en elde interfaz de usuario? Al editar la canalización, elija ... y, después, Desencadenadores.

    interfaz de usuario de configuración de canalización.

    Compruebe el Invalidar el desencadenador YAML desde aquí la configuración de los tipos de desencadenador (integración continua o validación de solicitudes de incorporación de cambios) disponibles para el repositorio.

    invalidar el desencadenador YAML desde aquí.

  • Los webhooks se usan para comunicar actualizaciones de Bitbucket a Azure Pipelines. En Bitbucket, vaya a la configuración del repositorio y, a continuación, a Webhooks. Compruebe que los webhooks existen.

  • ¿La canalización está en pausa o deshabilitada? Abra el editor de la canalización y, a continuación, seleccione Configuración para comprobar. Si la canalización está en pausa o deshabilitada, los desencadenadores no funcionan.

  • ¿Ha actualizado el archivo YAML en la rama correcta? Si inserta una actualización en una rama, el archivo YAML de esa misma rama rige el comportamiento de ci. Si inserta una actualización en una rama de origen, el archivo YAML resultante de combinar la rama de origen con la rama de destino rige el comportamiento de la solicitud de incorporación de cambios. Asegúrese de que el archivo YAML de la rama correcta tiene la configuración de CI o PR necesaria.

  • ¿Ha configurado el desencadenador correctamente? Al definir un desencadenador YAML, puede especificar cláusulas include y exclude para ramas, etiquetas y rutas de acceso. Asegúrese de que la cláusula include coincide con los detalles de la confirmación y que la cláusula exclude no las excluye. Compruebe la sintaxis de los desencadenadores y asegúrese de que es precisa.

  • ¿Ha usado variables para definir el desencadenador o las rutas de acceso? No se admite.

  • ¿Ha usado plantillas para el archivo YAML? Si es así, asegúrese de que los desencadenadores están definidos en el archivo YAML principal. No se admiten los desencadenadores definidos dentro de los archivos de plantilla.

  • ¿Ha excluido las ramas o rutas de acceso a las que ha insertado los cambios? Pruebe insertando un cambio en una ruta de acceso incluida en una rama incluida. Tenga en cuenta que las rutas de acceso de los desencadenadores distinguen mayúsculas de minúsculas. Asegúrese de usar el mismo caso que los de carpetas reales al especificar las rutas de acceso en desencadenadores.

  • ¿Acabas de insertar una nueva rama? Si es así, es posible que la nueva rama no inicie una nueva ejecución. Consulte la sección "Comportamiento de desencadenadores cuando se crean nuevas ramas".

Mis desencadenadores de CI o PR han funcionado bien. Pero dejaron de trabajar ahora.

En primer lugar, siga los pasos de solución de problemas de la pregunta anterior. A continuación, siga estos pasos adicionales:

  • ¿Tiene conflictos de combinación en la solicitud de incorporación de cambios? Para una solicitud de incorporación de cambios que no desencadenó una canalización, ábrala y compruebe si tiene un conflicto de combinación. Resuelva el conflicto de combinación.

  • ¿Experimenta un retraso en el procesamiento de eventos de inserción o solicitud de incorporación de cambios? Normalmente, puede comprobarlo si el problema es específico de una sola canalización o es común a todas las canalizaciones o repositorios del proyecto. Si una actualización de inserción o solicitud de incorporación de cambios a cualquiera de los repositorios muestra este síntoma, es posible que experimentemos retrasos en el procesamiento de los eventos de actualización. Compruebe si estamos experimentando una interrupción del servicio en nuestra página de estado de . Si la página de estado muestra un problema, nuestro equipo debe haber empezado a trabajar en él. Compruebe la página con frecuencia para ver las actualizaciones del problema.

No quiero que los usuarios invaliden la lista de ramas de desencadenadores cuando actualizan el archivo YAML. ¿Cómo puedo hacer esto?

Los usuarios con permisos para contribuir código pueden actualizar el archivo YAML e incluir o excluir ramas adicionales. Como resultado, los usuarios pueden incluir su propia característica o rama de usuario en su archivo YAML e insertar esa actualización en una característica o rama de usuario. Esto puede hacer que la canalización se desencadene para todas las actualizaciones de esa rama. Si desea evitar este comportamiento, puede hacer lo siguiente:

  1. Edite la canalización en la interfaz de usuario de Azure Pipelines.
  2. Vaya al menú Desencadenadores de .
  3. Seleccione Invalidar el desencadenador de integración continua de YAML desde aquí.
  4. Especifique las ramas que se van a incluir o excluir para el desencadenador.

Al seguir estos pasos, se omiten los desencadenadores de CI especificados en el archivo YAML.

Versión incorrecta

Se usa una versión incorrecta del archivo YAML en la canalización. ¿Por qué ocurre esto?

  • En el caso de los desencadenadores de CI, el archivo YAML que se encuentra en la rama que está insertando se evalúa para ver si se debe ejecutar una compilación de CI.
  • En el caso de los desencadenadores de pr, el archivo YAML resultante de combinar las ramas de origen y destino de la pr se evalúa para ver si se debe ejecutar una compilación de PR.