Creare repository Di Bitbucket Cloud

  • Articolo

Servizi di Azure DevOps

Azure Pipelines può compilare e convalidare automaticamente ogni richiesta pull ed eseguire il commit nel repository Bitbucket Cloud. Questo articolo descrive come configurare l'integrazione tra Bitbucket Cloud e Azure Pipelines.

Bitbucket e Azure Pipelines sono due servizi indipendenti che si integrano bene insieme. Gli utenti di Bitbucket Cloud non ottengono automaticamente l'accesso ad Azure Pipelines. È necessario aggiungerli in modo esplicito ad Azure Pipelines.

Accesso ai repository Bitbucket

Per creare una nuova pipeline, selezionare prima un repository Bitbucket Cloud e quindi un file YAML in tale repository. Il repository in cui è presente il file YAML è denominato self repository. Per impostazione predefinita, si tratta del repository che verrà compilato dalla pipeline.

In un secondo momento è possibile configurare la pipeline per l'estrazione di un repository o di più repository diversi. Per informazioni su come eseguire questa operazione, vedere Checkout multi-repo.

È necessario concedere ad Azure Pipelines l'accesso ai repository per recuperare il codice durante le compilazioni. Inoltre, l'utente che configura la pipeline deve avere accesso amministratore a Bitbucket, poiché tale identità viene usata per registrare un webhook in Bitbucket.

Esistono due tipi di autenticazione per concedere ad Azure Pipelines l'accesso ai repository Bitbucket Cloud durante la creazione di una pipeline.

Tipo di autenticazione Le pipeline vengono eseguite con
1. OAuth Identità personale di Bitbucket
2. Nome utente e password Identità personale di Bitbucket

Autenticazione OAuth

OAuth è il tipo di autenticazione più semplice da usare per i repository nell'account Bitbucket. Gli aggiornamenti dello stato di Bitbucket verranno eseguiti per conto dell'identità di Bitbucket personale. Affinché le pipeline continuino a funzionare, l'accesso al repository deve rimanere attivo.

Per usare OAuth, accedere a Bitbucket quando richiesto durante la creazione della pipeline. Fare quindi clic su Autorizza per autorizzare con OAuth. Una connessione OAuth verrà salvata nel progetto Azure DevOps per usarla in un secondo momento, nonché usata nella pipeline in fase di creazione.

Nota

Il numero massimo di repository Bitbucket che l'interfaccia utente di Azure DevOps Services può caricare è 2.000.

Autenticazione della password

Le compilazioni e gli aggiornamenti dello stato di Bitbucket verranno eseguiti per conto dell'identità personale. Affinché le compilazioni continuino a funzionare, l'accesso al repository deve rimanere attivo.

Per creare una connessione con password, vedere Connessioni al servizio nelle impostazioni del progetto Azure DevOps. Creare una nuova connessione al servizio Bitbucket e specificare il nome utente e la password per connettersi al repository Bitbucket Cloud.

Trigger CI

I trigger di integrazione continua (CI) causano l'esecuzione di una pipeline ogni volta che si esegue il push di un aggiornamento nei rami specificati o si esegue il push dei tag specificati.

Le pipeline YAML vengono configurate per impostazione predefinita con un trigger CI in tutti i rami, a meno che l'impostazione Disabilita trigger CI YAML implicito, introdotta nello sprint 227 di Azure DevOps, non sia abilitata. L'impostazione Del trigger CI YAML implicito può essere configurata a livello di organizzazione o a livello di progetto. Quando l'impostazione disabilita il trigger CI YAML implicito è abilitata, i trigger CI per le pipeline YAML non sono abilitati se la pipeline YAML non include una trigger sezione. Per impostazione predefinita, il trigger CI YAML implicito non è abilitato.

Rami

È possibile controllare quali rami ottengono trigger CI con una sintassi semplice:

trigger:
- main
- releases/*

È possibile specificare il nome completo del ramo ( ad esempio , main) o un carattere jolly (ad esempio, releases/*). Per informazioni sulla sintassi con caratteri jolly, vedere Caratteri jolly.

Nota

Non è possibile usare le variabili nei trigger, perché le variabili vengono valutate in fase di esecuzione (dopo che il trigger è stato attivato).

Nota

Se si usano modelli per creare file YAML, è possibile specificare solo i trigger nel file YAML principale per la pipeline. Non è possibile specificare trigger nei file modello.

Per i trigger più complessi che usano exclude o batch, è necessario usare la sintassi completa, come illustrato nell'esempio seguente.

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

Nell'esempio precedente, la pipeline verrà attivata se viene eseguito il push di una modifica in main o in qualsiasi ramo di rilascio. Tuttavia, non verrà attivato se viene apportata una modifica a un ramo delle versioni che inizia con old.

Se si specifica una exclude clausola senza clausola include , equivale a specificare * nella include clausola .

Oltre a specificare i nomi dei rami negli branches elenchi, è anche possibile configurare i trigger in base ai tag usando il formato seguente:

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

Se non sono stati specificati trigger e l'impostazione Disabilita trigger CI YAML implicito non è abilitata, il valore predefinito è come se fosse stato scritto:

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

Importante

Quando si specifica un trigger, sostituisce il trigger implicito predefinito e solo i push ai rami configurati in modo esplicito da includere attiveranno una pipeline. Le inclusioni vengono elaborate per prime e quindi le esclusioni vengono rimosse da tale elenco.

Invio in batch di esecuzioni CI

Se si hanno molti membri del team che caricano spesso le modifiche, è consigliabile ridurre il numero di esecuzioni avviate. Se si imposta su batchtrue, quando una pipeline è in esecuzione, il sistema attende fino al completamento dell'esecuzione, quindi avvia un'altra esecuzione con tutte le modifiche non ancora compilate.

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

Nota

batch non è supportato nei trigger di risorse del repository.

Per chiarire questo esempio, si supponga che un push A in main ha causato l'esecuzione della pipeline precedente. Mentre la pipeline è in esecuzione, vengono eseguiti push aggiuntivi B e C si verificano nel repository. Questi aggiornamenti non avviano immediatamente nuove esecuzioni indipendenti. Dopo il completamento della prima esecuzione, tuttavia, tutti i push fino a quel punto di tempo vengono raggruppati insieme e viene avviata una nuova esecuzione.

Nota

Se la pipeline ha più processi e fasi, la prima esecuzione dovrebbe comunque raggiungere uno stato terminale completando o ignorando tutti i processi e le fasi prima che la seconda esecuzione possa essere avviata. Per questo motivo, è necessario prestare attenzione quando si usa questa funzionalità in una pipeline con più fasi o approvazioni. Se si vuole eseguire il batch delle compilazioni in questi casi, è consigliabile suddividere il processo CI/CD in due pipeline, una per la compilazione (con invio in batch) e una per le distribuzioni.

Percorsi

È possibile specificare i percorsi di file da includere o escludere.

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

Quando si specificano percorsi, è necessario specificare in modo esplicito i rami da attivare se si usa Azure DevOps Server 2019.1 o versione precedente. Non è possibile attivare una pipeline con solo un filtro di percorso; è inoltre necessario disporre di un filtro di ramo e i file modificati che corrispondono al filtro del percorso devono essere da un ramo che corrisponde al filtro di ramo. Se si usa Azure DevOps Server 2020 o versione successiva, è possibile omettere branches di filtrare tutti i rami insieme al filtro del percorso.

I caratteri jolly sono supportati per i filtri di percorso. Ad esempio, è possibile includere tutti i percorsi che corrispondono a src/app/**/myapp*. È possibile usare caratteri jolly (**, *o ?) quando si specificano filtri di percorso.

  • I percorsi vengono sempre specificati in relazione alla radice del repository.
  • Se non si impostano filtri di percorso, la cartella radice del repository viene inclusa in modo implicito per impostazione predefinita.
  • Se si esclude un percorso, non è possibile includerlo anche a meno che non venga qualificato in una cartella più approfondita. Ad esempio, se si esclude /tools , è possibile includere /tools/trigger-runs-on-these
  • L'ordine dei filtri di percorso non è importante.
  • I percorsi in Git fanno distinzione tra maiuscole e minuscole. Assicurarsi di usare lo stesso caso delle cartelle reali.
  • Non è possibile usare le variabili nei percorsi, perché le variabili vengono valutate in fase di esecuzione (dopo che il trigger è stato attivato).

Nota

Per i repository di Bitbucket Cloud, l'uso branches della sintassi è l'unico modo per specificare trigger di tag. La tags: sintassi non è supportata per Bitbucket.

Rifiuto esplicito dell'integrazione continua

Disabilitazione del trigger CI

È possibile rifiutare esplicitamente i trigger di integrazione continua specificando trigger: none.

# A pipeline with no CI trigger
trigger: none

Importante

Quando si esegue il push di una modifica in un ramo, il file YAML in tale ramo viene valutato per determinare se deve essere avviata un'esecuzione CI.

Ignorare l'integrazione continua per i singoli commit

È anche possibile indicare ad Azure Pipelines di ignorare l'esecuzione di una pipeline che normalmente viene attivata da un push. È sufficiente includere [skip ci] nel messaggio o nella descrizione di uno dei commit che fanno parte di un push e Azure Pipelines ignorerà l'esecuzione dell'integrazione continua per questo push. È anche possibile usare una delle varianti seguenti.

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

Uso del tipo di trigger in condizioni

È uno scenario comune per eseguire passaggi, processi o fasi diverse nella pipeline a seconda del tipo di trigger che ha avviato l'esecuzione. A tale scopo, è possibile usare la variabile Build.Reasondi sistema . Ad esempio, aggiungere la condizione seguente al passaggio, al processo o alla fase per escluderla dalle convalide della richiesta pull.

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

Comportamento dei trigger quando vengono creati nuovi rami

È comune configurare più pipeline per lo stesso repository. Ad esempio, potrebbe essere disponibile una pipeline per compilare la documentazione per l'app e un'altra per compilare il codice sorgente. È possibile configurare i trigger CI con filtri di ramo e filtri di percorso appropriati in ognuna di queste pipeline. Ad esempio, è possibile attivare una pipeline quando si esegue il push di un aggiornamento nella docs cartella e un'altra da attivare quando si esegue il push di un aggiornamento nel codice dell'applicazione. In questi casi, è necessario comprendere come vengono attivate le pipeline quando viene creato un nuovo ramo.

Ecco il comportamento quando si esegue il push di un nuovo ramo (che corrisponde ai filtri del ramo) nel repository:

  • Se la pipeline dispone di filtri di percorso, verrà attivata solo se il nuovo ramo include modifiche ai file che corrispondono al filtro di percorso.
  • Se la pipeline non dispone di filtri di percorso, verrà attivata anche se non sono presenti modifiche nel nuovo ramo.

Caratteri jolly

Quando si specifica un ramo, un tag o un percorso, è possibile usare un nome esatto o un carattere jolly. I criteri con caratteri jolly consentono di * trovare la corrispondenza con zero o più caratteri e ? di trovare una corrispondenza con un singolo carattere.

  • Se si avvia il modello con * in una pipeline YAML, è necessario eseguire il wrapping del modello tra virgolette, ad esempio "*-releases".
  • Per rami e tag:
    • Un carattere jolly può essere visualizzato in qualsiasi punto del modello.
  • Per i percorsi:
    • In Azure DevOps Server 2022 e versioni successive, incluso Azure DevOps Services, un carattere jolly può essere visualizzato ovunque all'interno di un modello di percorso ed è possibile usare * o ?.
    • In Azure DevOps Server 2020 e versioni precedenti è possibile includere * come carattere finale, ma non esegue alcuna operazione diversa dalla specifica del nome della directory da solo. Non è possibile includere * al centro di un filtro di percorso e non è possibile usare ?.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Trigger di richiesta pull

I trigger di richiesta pull causano l'esecuzione di una pipeline ogni volta che viene aperta una richiesta pull con uno dei rami di destinazione specificati o quando vengono eseguiti aggiornamenti a tale richiesta pull.

Rami

È possibile specificare i rami di destinazione durante la convalida delle richieste pull. Ad esempio, per convalidare le richieste pull destinate master a e releases/*, è possibile usare il trigger seguente pr .

pr:
- main
- releases/*

Questa configurazione avvia una nuova esecuzione la prima volta che viene creata una nuova richiesta pull e dopo ogni aggiornamento eseguito alla richiesta pull.

È possibile specificare il nome completo del ramo ( ad esempio , master) o un carattere jolly (ad esempio, releases/*).

Nota

Non è possibile usare le variabili nei trigger, perché le variabili vengono valutate in fase di esecuzione (dopo che il trigger è stato attivato).

Nota

Se si usano modelli per creare file YAML, è possibile specificare solo i trigger nel file YAML principale per la pipeline. Non è possibile specificare trigger nei file modello.

Ogni nuova esecuzione compila il commit più recente dal ramo di origine della richiesta pull. Questo è diverso dal modo in cui Azure Pipelines compila le richieste pull in altri repository (ad esempio, Azure Repos o GitHub), in cui compila il commit di merge. Purtroppo Bitbucket non espone informazioni sul commit di merge, che contiene il codice unito tra i rami di origine e di destinazione della richiesta pull.

Se nel file YAML non pr vengono visualizzati trigger, le convalide delle richieste pull vengono abilitate automaticamente per tutti i rami, come se fosse stato scritto il trigger seguente pr . Questa configurazione attiva una compilazione quando viene creata una richiesta pull e quando i commit vengono inseriti nel ramo di origine di qualsiasi richiesta pull attiva.

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

Importante

Quando si specifica un pr trigger, sostituisce il trigger implicito pr predefinito e solo i push ai rami configurati in modo esplicito da includere attiveranno una pipeline.

Per i trigger più complessi che devono escludere determinati rami, è necessario usare la sintassi completa, come illustrato nell'esempio seguente.

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

Percorsi

È possibile specificare i percorsi di file da includere o escludere. Ad esempio:

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

Suggerimenti:

  • I caratteri jolly non sono supportati con i filtri di percorso.
  • I percorsi vengono sempre specificati in relazione alla radice del repository.
  • Se non si impostano filtri di percorso, la cartella radice del repository viene inclusa in modo implicito per impostazione predefinita.
  • Se si esclude un percorso, non è possibile includerlo anche a meno che non venga qualificato in una cartella più approfondita. Ad esempio, se si esclude /tools , è possibile includere /tools/trigger-runs-on-these
  • L'ordine dei filtri di percorso non è importante.
  • I percorsi in Git fanno distinzione tra maiuscole e minuscole. Assicurarsi di usare lo stesso caso delle cartelle reali.
  • Non è possibile usare le variabili nei percorsi, perché le variabili vengono valutate in fase di esecuzione (dopo che il trigger è stato attivato).

Aggiornamenti di più richieste pull

È possibile specificare se gli aggiornamenti aggiuntivi di una richiesta pull devono annullare le esecuzioni di convalida in corso per la stessa richiesta pull. Il valore predefinito è true.

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

Rifiuto esplicito della convalida della richiesta pull

È possibile rifiutare esplicitamente la convalida della richiesta pull specificando pr: none.

# no PR triggers
pr: none

Per altre informazioni, vedere Trigger pr nello schema YAML.

Nota

Se il pr trigger non viene attivato, assicurarsi di non aver eseguito l'override dei trigger di richiesta pull YAML nell'interfaccia utente.

Esecuzioni informative

Un'esecuzione informativa indica che Azure DevOps non è riuscito a recuperare il codice sorgente di una pipeline YAML. Il recupero del codice sorgente viene eseguito in risposta a eventi esterni, ad esempio un commit sottoposto a push. Si verifica anche in risposta a trigger interni, ad esempio, per verificare se sono presenti modifiche al codice e avviare o meno un'esecuzione pianificata. Il recupero del codice sorgente può avere esito negativo per diversi motivi, con una limitazione frequente delle richieste da parte del provider di repository Git. L'esistenza di un'esecuzione informativa non significa necessariamente che Azure DevOps eseguirà la pipeline.

Un'esecuzione informativa è simile alla schermata seguente.

Screenshot of an informational pipeline run.

È possibile riconoscere un'esecuzione informativa con gli attributi seguenti:

  • Lo stato è Canceled
  • La durata è < 1s
  • Il nome dell'esecuzione contiene uno dei testi seguenti:
    • 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.
  • Il nome dell'esecuzione contiene in genere l'errore BitBucket/GitHub che ha causato l'esito negativo del caricamento della pipeline YAML
  • Nessuna fase/processo/passaggi

Altre informazioni sulle esecuzioni informative.

Limiti

Azure Pipelines carica un massimo di 2000 rami da un repository in elenchi a discesa nel portale di Azure Devops, ad esempio nel ramo predefinito per le compilazioni manuali e pianificate o quando si sceglie un ramo quando si esegue manualmente una pipeline. Se non viene visualizzato il ramo desiderato nell'elenco, digitare manualmente il nome del ramo desiderato.

Domande frequenti

I problemi relativi all'integrazione di Bitbucket rientrano nelle categorie seguenti:

  • Trigger con errori: la pipeline non viene attivata quando si esegue il push di un aggiornamento al repository.
  • Versione errata: la pipeline viene eseguita, ma usa una versione imprevista dell'origine/YAML.

Trigger con errori

È stata appena creata una nuova pipeline YAML con trigger CI/PR, ma la pipeline non viene attivata.

Seguire ognuno di questi passaggi per risolvere i problemi relativi ai trigger con errori:

  • I webhook vengono usati per comunicare gli aggiornamenti da Bitbucket ad Azure Pipelines. In Bitbucket passare alle impostazioni per il repository e quindi a Webhook. Verificare che i webhook esistano.

  • La pipeline è sospesa o disabilitata? Aprire l'editor per la pipeline e quindi selezionare Impostazioni da controllare. Se la pipeline è sospesa o disabilitata, i trigger non funzionano.

  • Il file YAML è stato aggiornato nel ramo corretto? Se si esegue il push di un aggiornamento in un ramo, il file YAML in tale ramo regola il comportamento di integrazione continua. Se si esegue il push di un aggiornamento in un ramo di origine, il file YAML risultante dall'unione del ramo di origine con il ramo di destinazione determina il comportamento della richiesta pull. Assicurarsi che il file YAML nel ramo corretto disponga della configurazione CI o pr necessaria.

  • Il trigger è stato configurato correttamente? Quando si definisce un trigger YAML, è possibile specificare clausole di inclusione ed esclusione per rami, tag e percorsi. Assicurarsi che la clausola include corrisponda ai dettagli del commit e che la clausola exclude non le esclude. Controllare la sintassi per i trigger e assicurarsi che sia accurato.

  • Sono state usate variabili per definire il trigger o i percorsi? Questo non è supportato.

  • Sono stati usati modelli per il file YAML? In tal caso, assicurarsi che i trigger siano definiti nel file YAML principale. I trigger definiti all'interno dei file modello non sono supportati.

  • Sono stati esclusi i rami o i percorsi in cui è stato eseguito il push delle modifiche? Eseguire il test eseguendo il push di una modifica a un percorso incluso in un ramo incluso. Si noti che i percorsi nei trigger fanno distinzione tra maiuscole e minuscole. Assicurarsi di usare lo stesso caso di quelle delle cartelle reali quando si specificano i percorsi nei trigger.

  • È stato appena eseguito il push di un nuovo ramo? In tal caso, il nuovo ramo potrebbe non avviare una nuova esecuzione. Vedere la sezione "Comportamento dei trigger quando vengono creati nuovi rami".

I trigger CI o PR funzionano correttamente. Ma, hanno smesso di lavorare ora.

Prima di tutto, esaminare i passaggi per la risoluzione dei problemi nella domanda precedente. Seguire quindi questi passaggi aggiuntivi:

  • Sono presenti conflitti di unione nella richiesta pull? Per una richiesta pull che non ha attivato una pipeline, aprirla e verificare se presenta un conflitto di merge. Risolvere il conflitto di merge.

  • Si verifica un ritardo nell'elaborazione di eventi push o pull? In genere è possibile verificare questo problema verificando se il problema è specifico di una singola pipeline o è comune a tutte le pipeline o repository nel progetto. Se un aggiornamento push o una richiesta pull a uno dei repository presenta questo sintomo, potrebbero verificarsi ritardi nell'elaborazione degli eventi di aggiornamento. Controllare se si verifica un'interruzione del servizio nella pagina di stato. Se la pagina di stato mostra un problema, il team deve aver già iniziato a lavorare su di esso. Controllare frequentemente la pagina per gli aggiornamenti sul problema.

Non si vuole che gli utenti esestituiscono l'elenco dei rami per i trigger quando aggiornano il file YAML. Come posso fare?

Gli utenti con autorizzazioni per contribuire al codice possono aggiornare il file YAML ed escludere rami aggiuntivi. Di conseguenza, gli utenti possono includere la propria funzionalità o un ramo utente nel file YAML e eseguire il push di tale aggiornamento a una funzionalità o a un ramo utente. Ciò può causare l'attivazione della pipeline per tutti gli aggiornamenti di tale ramo. Se si vuole evitare questo comportamento, è possibile:

  1. Modificare la pipeline nell'interfaccia utente di Azure Pipelines.
  2. Passare al menu Trigger .
  3. Selezionare Override del trigger di integrazione continua YAML da qui.
  4. Specificare i rami da includere o escludere per il trigger.

Quando si seguono questi passaggi, tutti i trigger CI specificati nel file YAML vengono ignorati.

Versione errata

Nella pipeline viene usata una versione errata del file YAML. Perché?

  • Per i trigger CI, il file YAML presente nel ramo di cui si esegue il push viene valutato per verificare se deve essere eseguita una compilazione CI.
  • Per i trigger pr, il file YAML risultante dall'unione dei rami di origine e di destinazione della richiesta pull viene valutato per verificare se deve essere eseguita una compilazione pull.