Creare repository Di Bitbucket Cloud

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

È 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.

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.

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.

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

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.

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

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.

È 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 trigger di integrazione continua o richiesta pull YAML vengono sottoposti a override dalle impostazioni della pipeline nell'interfaccia utente? Durante la modifica della pipeline, scegliere ... e quindi Trigger.

  

  Controllare l'impostazione Esegui l'override del trigger YAML da qui per i tipi di trigger (integrazione continua o convalida della richiesta pull) disponibili per il repository.

  

• 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.