Crie repositórios Bitbucket Cloud

Serviços de DevOps do Azure

O Azure Pipelines pode criar e validar automaticamente cada solicitação pull e confirmar em seu repositório Bitbucket Cloud. Este artigo descreve como configurar a integração entre o Bitbucket Cloud e o Azure Pipelines.

Bitbucket e Azure Pipelines são dois serviços independentes que se integram bem juntos. Seus usuários do Bitbucket Cloud não obtêm acesso automaticamente ao Azure Pipelines. Você deve adicioná-los explicitamente ao Azure Pipelines.

Acesso aos repositórios do Bitbucket

Os Pipelines do Azure devem ter acesso aos seus repositórios para buscar o código durante as compilações. Além disso, o usuário que configura o pipeline deve ter acesso de administrador ao Bitbucket, já que essa identidade é usada para registrar um webhook no Bitbucket.

Há 2 tipos de autenticação para conceder acesso ao Azure Pipelines aos seus repositórios Bitbucket Cloud durante a criação de um pipeline.

Autenticação OAuth

OAuth é o tipo de autenticação mais simples de começar para repositórios em sua conta Bitbucket. As atualizações de status do Bitbucket serão realizadas em nome de sua identidade pessoal do Bitbucket. Para que os pipelines continuem funcionando, o acesso ao repositório deve permanecer ativo.

Para usar o OAuth, faça login no Bitbucket quando solicitado durante a criação do pipeline. Em seguida, clique em Autorizar para autorizar com OAuth. Uma conexão OAuth será salva em seu projeto de DevOps do Azure para uso posterior, bem como usada no pipeline que está sendo criado.

Autenticação da palavra-passe

Compilações e atualizações de status do Bitbucket serão realizadas em nome de sua identidade pessoal. Para que as compilações continuem funcionando, o acesso ao repositório deve permanecer ativo.

Para criar uma conexão de senha, visite Conexões de serviço em suas configurações de projeto do Azure DevOps. Crie uma nova conexão de serviço Bitbucket e forneça o nome de usuário e senha para se conectar ao seu repositório Bitbucket Cloud.

Desencadeadores de IC

Os gatilhos de integração contínua (CI) fazem com que um pipeline seja executado sempre que você envia uma atualização para as ramificações especificadas ou envia tags especificadas.

trigger:
- main
- releases/*

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

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

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

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

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

# A pipeline with no CI trigger
trigger: none

Ignorando IC para confirmações individuais

Você também pode dizer ao Azure Pipelines para ignorar a execução de um pipeline que um push normalmente acionaria. Basta incluir [skip ci] na mensagem ou descrição qualquer uma das confirmações que fazem parte de um push, e o Azure Pipelines ignorará a execução do CI para esse push. Você também pode usar qualquer uma das seguintes variações.

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

Usando o tipo de gatilho em condições

É um cenário comum executar diferentes etapas, trabalhos ou estágios em seu pipeline, dependendo do tipo de gatilho que iniciou a execução. Você pode fazer isso usando a variável Build.Reasonde sistema . Por exemplo, adicione a seguinte condição à sua etapa, trabalho ou estágio para excluí-la das validações de RP.

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

Comportamento de gatilhos quando novas ramificações são criadas

É comum configurar vários pipelines para o mesmo repositório. Por exemplo, você pode ter um pipeline para criar os documentos para seu aplicativo e outro para criar o código-fonte. Você pode configurar gatilhos de CI com filtros de ramificação e filtros de caminho apropriados em cada um desses pipelines. Por exemplo, você pode querer que um pipeline seja acionado quando você enviar uma atualização por push para a pasta e outro para disparar quando você enviar por push uma atualização para o código do docs aplicativo. Nesses casos, você precisa entender como os pipelines são acionados quando uma nova ramificação é criada.

Aqui está o comportamento quando você envia uma nova ramificação (que corresponde aos filtros de ramificação) para o repositório:

• Se o pipeline tiver filtros de caminho, ele será acionado somente se a nova ramificação tiver alterações em arquivos que correspondam a esse filtro de caminho.
• Se o pipeline não tiver filtros de caminho, ele será acionado mesmo que não haja alterações na nova ramificação.

Carateres universais

Ao especificar uma ramificação, marca ou caminho, você pode usar um nome exato ou um curinga. Os padrões curinga permitem * corresponder a zero ou mais caracteres e corresponder a um único caractere ? .

• Se você iniciar seu padrão com * em um pipeline YAML, deverá envolver o padrão entre aspas, como "*-releases".
• Para ramificações e tags:
  • Um curinga pode aparecer em qualquer lugar no padrão.
• Para caminhos:
  • No Azure DevOps Server 2022 e superior, incluindo os Serviços de DevOps do Azure, um curinga pode aparecer em qualquer lugar dentro de um padrão de caminho e você pode usar * ou ?.
  • No Azure DevOps Server 2020 e inferior, você pode incluir * como o caractere final, mas ele não faz nada diferente de especificar o nome do diretório por si só. Você não pode incluir * no meio de um filtro de caminho e não pode usar ?o .

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Gatilhos de RP

Os gatilhos de solicitação pull (PR) fazem com que um pipeline seja executado sempre que uma solicitação pull é aberta com uma das ramificações de destino especificadas ou quando atualizações são feitas para essa solicitação pull.

pr:
- main
- releases/*

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

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

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

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

# no PR triggers
pr: none

Execuções informativas

Uma execução informativa informa que o Azure DevOps não conseguiu recuperar o código-fonte de um pipeline YAML. A recuperação do código-fonte acontece em resposta a eventos externos, por exemplo, uma confirmação enviada. Isso também acontece em resposta a gatilhos internos, por exemplo, para verificar se há alterações de código e iniciar uma execução agendada ou não. A recuperação do código-fonte pode falhar por vários motivos, sendo um deles frequente a limitação de solicitações pelo provedor do repositório git. A existência de uma execução informativa não significa necessariamente que o Azure DevOps iria executar o pipeline.

Uma execução informativa se parece com a captura de tela a seguir.

Você pode reconhecer uma execução informacional pelos seguintes atributos:

• O status é Canceled
• A duração é < 1s
• O nome da execução contém um dos seguintes textos:
  • 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.
• O nome da execução geralmente contém o erro BitBucket / GitHub que causou a falha na carga do pipeline YAML
• Sem etapas / trabalhos / etapas

Saiba mais sobre execuções informativas.

Limitações

O Azure Pipelines carrega um máximo de 2000 ramificações de um repositório em listas suspensas no Portal de Devops do Azure, por exemplo, na configuração Ramificação padrão para compilações manuais e agendadas ou ao escolher uma ramificação ao executar um pipeline manualmente. Se você não vir a ramificação desejada na lista, digite o nome da ramificação desejada manualmente.

FAQ

Problemas relacionados à integração do Bitbucket se enquadram nas seguintes categorias:

• Gatilhos com falha: Meu pipeline não está sendo acionado quando envio uma atualização para o repositório.
• Versão errada: Meu pipeline é executado, mas está usando uma versão inesperada do source/YAML.

Gatilhos com falha

Acabei de criar um novo pipeline YAML com gatilhos CI/PR, mas o pipeline não está sendo acionado.

Siga cada uma destas etapas para solucionar problemas de seus gatilhos com falha:

• Os gatilhos YAML CI ou PR são substituídos pelas configurações de pipeline na interface do usuário? Ao editar seu pipeline, escolha ... e, em seguida, Triggers.

  

  Verifique a configuração Substituir o gatilho YAML daqui para os tipos de gatilho (Integração contínua ou Validação de solicitação pull) disponíveis para seu repositório.

  

• Webhooks são usados para comunicar atualizações do Bitbucket para o Azure Pipelines. No Bitbucket, navegue até as configurações do seu repositório e, em seguida, para Webhooks. Verifique se os webhooks existem.

• Seu pipeline está pausado ou desativado? Abra o editor do pipeline e selecione Configurações para verificar. Se o pipeline estiver pausado ou desativado, os gatilhos não funcionarão.

• Você atualizou o arquivo YAML na ramificação correta? Se você enviar uma atualização para uma ramificação, o arquivo YAML nessa mesma ramificação governará o comportamento de CI. Se você enviar uma atualização para uma ramificação de origem, o arquivo YAML resultante da mesclagem da ramificação de origem com a ramificação de destino governará o comportamento de RP. Certifique-se de que o arquivo YAML na ramificação correta tem a configuração de CI ou PR necessária.

• Você configurou o gatilho corretamente? Ao definir um gatilho YAML, você pode especificar cláusulas de inclusão e exclusão para ramificações, tags e caminhos. Certifique-se de que a cláusula include corresponda aos detalhes da sua confirmação e que a cláusula de exclusão não os exclua. Verifique a sintaxe dos gatilhos e certifique-se de que está correta.

• Você usou variáveis na definição do gatilho ou dos caminhos? Isso não é apoiado.

• Você usou modelos para o seu arquivo YAML? Em caso afirmativo, certifique-se de que seus gatilhos estão definidos no arquivo YAML principal. Não há suporte para gatilhos definidos dentro de arquivos de modelo.

• Excluiu os ramos ou caminhos para os quais empurrou as suas mudanças? Teste empurrando uma alteração para um caminho incluído em uma ramificação incluída. Observe que os caminhos nos gatilhos diferenciam maiúsculas de minúsculas. Certifique-se de usar o mesmo caso que os de pastas reais ao especificar os caminhos em gatilhos.

• Você acabou de empurrar um novo ramo? Em caso afirmativo, a nova ramificação pode não iniciar uma nova execução. Consulte a seção "Comportamento dos gatilhos quando novas ramificações são criadas".

Meus gatilhos de CI ou RP têm funcionado bem. Mas, eles pararam de trabalhar agora.

Primeiro, siga as etapas de solução de problemas na pergunta anterior. Em seguida, siga estes passos adicionais:

• Tem conflitos de fusão no seu PR? Para um RP que não acionou um pipeline, abra-o e verifique se ele tem um conflito de mesclagem. Resolva o conflito de mesclagem.

• Você está enfrentando um atraso no processamento de eventos push ou PR? Normalmente, você pode verificar isso vendo se o problema é específico de um único pipeline ou é comum a todos os pipelines ou repositórios em seu projeto. Se um push ou uma atualização de RP para qualquer um dos repositórios apresentar esse sintoma, podemos estar enfrentando atrasos no processamento dos eventos de atualização. Verifique se estamos passando por uma interrupção de serviço em nossa página de status. Se a página de status mostrar um problema, nossa equipe já deve ter começado a trabalhar nele. Verifique a página com frequência para atualizações sobre o problema.

Não quero que os usuários substituam a lista de ramificações para gatilhos quando atualizarem o arquivo YAML. Como posso fazê-lo?

Os usuários com permissões para contribuir com código podem atualizar o arquivo YAML e incluir/excluir ramificações adicionais. Como resultado, os usuários podem incluir seu próprio recurso ou ramificação de usuário em seu arquivo YAML e enviar essa atualização para um recurso ou ramificação de usuário. Isso pode fazer com que o pipeline seja acionado para todas as atualizações dessa ramificação. Se você quiser evitar esse comportamento, então você pode:

1. Edite o pipeline na interface do usuário do Azure Pipelines.
2. Navegue até o menu Triggers .
3. Selecione Substituir o gatilho de integração contínua YAML a partir daqui.
4. Especifique as ramificações a serem incluídas ou excluídas para o gatilho.

Quando você segue essas etapas, todos os gatilhos de CI especificados no arquivo YAML são ignorados.

Versão errada

Uma versão errada do arquivo YAML está sendo usada no pipeline. Porquê?

• Para gatilhos de CI, o arquivo YAML que está na ramificação que você está enviando é avaliado para ver se uma compilação de CI deve ser executada.
• Para gatilhos PR, o arquivo YAML resultante da fusão das ramificações de origem e destino do PR é avaliado para ver se uma compilação PR deve ser executada.