Skapa Bitbucket Cloud-lagringsplatser

Azure DevOps Services

Azure Pipelines kan automatiskt skapa och verifiera varje pull-begäran och checka in till din Bitbucket Cloud-lagringsplats. Den här artikeln beskriver hur du konfigurerar integreringen mellan Bitbucket Cloud och Azure Pipelines.

Bitbucket och Azure Pipelines är två oberoende tjänster som integreras väl tillsammans. Dina Bitbucket Cloud-användare får inte automatiskt åtkomst till Azure Pipelines. Du måste uttryckligen lägga till dem i Azure Pipelines.

Åtkomst till Bitbucket-lagringsplatser

Azure Pipelines måste beviljas åtkomst till dina lagringsplatser för att hämta koden under byggen. Dessutom måste användaren som konfigurerar pipelinen ha administratörsåtkomst till Bitbucket, eftersom den identiteten används för att registrera en webhook i Bitbucket.

Det finns två autentiseringstyper för att ge Azure Pipelines åtkomst till dina Bitbucket Cloud-lagringsplatser när du skapar en pipeline.

OAuth-autentisering

OAuth är den enklaste autentiseringstypen att komma igång med för lagringsplatser i ditt Bitbucket-konto. Bitbucket-statusuppdateringar utförs för din personliga Bitbucket-identitet. För att pipelines ska fortsätta att fungera måste lagringsplatsens åtkomst förbli aktiv.

Om du vill använda OAuth loggar du in på Bitbucket när du uppmanas att skapa pipelinen. Klicka sedan på Auktorisera för att auktorisera med OAuth. En OAuth-anslutning sparas i ditt Azure DevOps-projekt för senare användning, samt används i pipelinen som skapas.

Lösenordsverifiering

Uppdateringar av byggen och Bitbucket-status utförs för din personliga identitet. För att byggen ska fortsätta att fungera måste lagringsplatsens åtkomst förbli aktiv.

Om du vill skapa en lösenordsanslutning går du till Tjänstanslutningar i dina Azure DevOps-projektinställningar. Skapa en ny Bitbucket-tjänstanslutning och ange användarnamn och lösenord för att ansluta till Bitbucket Cloud-lagringsplatsen.

CI-utlösare

Utlösare för kontinuerlig integrering (CI) gör att en pipeline körs när du skickar en uppdatering till de angivna grenarna eller push-överför angivna taggar.

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

Hoppar över CI för enskilda incheckningar

Du kan också be Azure Pipelines att hoppa över att köra en pipeline som en push normalt utlöser. Inkludera [skip ci] bara i meddelandet eller beskrivningen av någon av incheckningarna som ingår i en push-överföring, så hoppar Azure Pipelines över att köra CI för den här push-överföringen. Du kan också använda någon av följande varianter.

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

Använda utlösartypen i villkor

Det är ett vanligt scenario att köra olika steg, jobb eller steg i pipelinen beroende på vilken typ av utlösare som startade körningen. Du kan göra detta med hjälp av systemvariabeln Build.Reason. Lägg till exempel till följande villkor i ditt steg, jobb eller steg för att undanta det från PR-valideringar.

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

Beteende för utlösare när nya grenar skapas

Det är vanligt att konfigurera flera pipelines för samma lagringsplats. Du kan till exempel ha en pipeline för att skapa dokumenten för din app och en annan för att skapa källkoden. Du kan konfigurera CI-utlösare med lämpliga förgreningsfilter och sökvägsfilter i var och en av dessa pipelines. Du kanske till exempel vill att en pipeline ska utlösas när du skickar en uppdatering till docs mappen och en annan ska utlösas när du skickar en uppdatering till programkoden. I dessa fall måste du förstå hur pipelines utlöses när en ny gren skapas.

Här är beteendet när du skickar en ny gren (som matchar grenfiltren) till lagringsplatsen:

• Om din pipeline har sökvägsfilter utlöses den endast om den nya grenen har ändringar i filer som matchar sökvägsfiltret.
• Om pipelinen inte har sökvägsfilter utlöses den även om det inte finns några ändringar i den nya grenen.

Jokertecken

När du anger en gren, tagg eller sökväg kan du använda ett exakt namn eller ett jokertecken. Med jokertecken kan * mönster matcha noll eller fler tecken och ? matcha ett enda tecken.

• Om du startar mönstret med * i en YAML-pipeline måste du omsluta mönstret med citattecken, till exempel "*-releases".
• För grenar och taggar:
  • Ett jokertecken kan visas var som helst i mönstret.
• För sökvägar:
  • I Azure DevOps Server 2022 och senare, inklusive Azure DevOps Services, kan ett jokertecken visas var som helst inom ett sökvägsmönster och du kan använda * eller ?.
  • I Azure DevOps Server 2020 och lägre kan du inkludera * som det sista tecknet, men det gör inget annat än att ange katalognamnet på egen hand. Du kanske inte tar med * i mitten av ett sökvägsfilter och du kanske inte använder ?.

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

PR-utlösare

Pull-begärandeutlösare (PR) gör att en pipeline körs när en pull-begäran öppnas med en av de angivna målgrenarna eller när uppdateringar görs i en sådan pull-begäran.

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

Informationskörningar

En informationskörning anger att Azure DevOps inte kunde hämta en YAML-pipelines källkod. Källkodshämtning sker som svar på externa händelser, till exempel en push-överföring. Det händer också som svar på interna utlösare, till exempel för att kontrollera om det finns kodändringar och starta en schemalagd körning eller inte. Källkodshämtningen kan misslyckas av flera orsaker, där en frekvent begäran begränsas av git-lagringsplatsens provider. Förekomsten av en informationskörning innebär inte nödvändigtvis att Azure DevOps skulle köra pipelinen.

En informationskörning ser ut som i följande skärmbild.

Du kan identifiera en informationskörning med följande attribut:

• Status är Canceled
• Varaktigheten är < 1s
• Körningsnamnet innehåller någon av följande texter:
  • 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.
• Körningsnamnet innehåller vanligtvis BitBucket/GitHub-felet som gjorde att YAML-pipelinebelastningen misslyckades
• Inga steg/jobb/steg

Läs mer om informationskörningar.

Begränsningar

Azure Pipelines läser in högst 2 000 grenar från en lagringsplats till listrutor i Azure Devops-portalen, till exempel i standardgrenen för manuella och schemalagda byggen , eller när du väljer en gren när du kör en pipeline manuellt. Om du inte ser önskad gren i listan skriver du önskat grennamn manuellt.

Vanliga frågor

Problem som rör Bitbucket-integrering finns i följande kategorier:

• Utlösare som misslyckas: Min pipeline utlöses inte när jag skickar en uppdatering till lagringsplatsen.
• Fel version: Min pipeline körs, men den använder en oväntad version av källan/YAML.

Felutlösare

Jag har precis skapat en ny YAML-pipeline med CI/PR-utlösare, men pipelinen utlöses inte.

Följ vart och ett av dessa steg för att felsöka dina felutlösare:

• Åsidosättas dina YAML CI- eller PR-utlösare av pipelineinställningar i användargränssnittet? När du redigerar din pipeline väljer du ... och sedan Utlösare.

  

  Kontrollera inställningen Åsidosätt YAML-utlösaren härifrån för de typer av utlösare (kontinuerlig integrering eller validering av pull-begäran) som är tillgängliga för lagringsplatsen.

  

• Webhooks används för att kommunicera uppdateringar från Bitbucket till Azure Pipelines. I Bitbucket navigerar du till inställningarna för lagringsplatsen och sedan till Webhooks. Kontrollera att webhooks finns.

• Har pipelinen pausats eller inaktiverats? Öppna redigeraren för pipelinen och välj sedan Inställningar att kontrollera. Om pipelinen är pausad eller inaktiverad fungerar inte utlösare.

• Har du uppdaterat YAML-filen i rätt gren? Om du skickar en uppdatering till en gren styr YAML-filen i samma gren CI-beteendet. Om du skickar en uppdatering till en källgren styr YAML-filen som uppstår när källgrenen slås samman med målgrenen PR-beteendet. Kontrollera att YAML-filen i rätt gren har nödvändig CI- eller PR-konfiguration.

• Har du konfigurerat utlösaren korrekt? När du definierar en YAML-utlösare kan du ange både inkludera och exkludera satser för grenar, taggar och sökvägar. Se till att inkluderingssatsen matchar informationen om incheckningen och att exkluderingssatsen inte utesluter dem. Kontrollera syntaxen för utlösarna och kontrollera att den är korrekt.

• Har du använt variabler för att definiera utlösaren eller sökvägarna? Det stöds inte.

• Använde du mallar för YAML-filen? I så fall kontrollerar du att utlösarna har definierats i yaml-huvudfilen. Utlösare som definieras i mallfiler stöds inte.

• Har du exkluderat de grenar eller sökvägar som du har push-överfört ändringarna till? Testa genom att push-överföra en ändring till en inkluderad sökväg i en inkluderad gren. Observera att sökvägarna i utlösare är skiftlägeskänsliga. Kontrollera att du använder samma skiftläge som för riktiga mappar när du anger sökvägarna i utlösare.

• Har du precis push-överfört en ny gren? I så fall kanske den nya grenen inte startar en ny körning. Se avsnittet "Beteende för utlösare när nya grenar skapas".

Mina CI- eller PR-utlösare har fungerat bra. Men de slutade fungera nu.

Gå först igenom felsökningsstegen i föregående fråga. Följ sedan dessa ytterligare steg:

• Har du sammanslagningskonflikter i din PR? För en PR som inte utlöste en pipeline öppnar du den och kontrollerar om den har en sammanslagningskonflikt. Lös sammanslagningskonflikten.

• Har du en fördröjning i bearbetningen av push- eller PR-händelser? Du kan vanligtvis kontrollera detta genom att se om problemet är specifikt för en enda pipeline eller är gemensamt för alla pipelines eller lagringsplatser i projektet. Om en push- eller PR-uppdatering till någon av lagringsplatserna uppvisar det här symptomet kan det uppstå fördröjningar i bearbetningen av uppdateringshändelserna. Kontrollera om det uppstår ett avbrott i tjänsten på statussidan. Om statussidan visar ett problem måste vårt team redan ha börjat arbeta med det. Kontrollera sidan ofta för att få uppdateringar om problemet.

Jag vill inte att användarna ska åsidosätta listan över grenar för utlösare när de uppdaterar YAML-filen. Hur gör jag?

Användare med behörighet att bidra med kod kan uppdatera YAML-filen och inkludera/exkludera ytterligare grenar. Därför kan användarna inkludera sin egen funktion eller användargren i sin YAML-fil och skicka uppdateringen till en funktion eller användargren. Detta kan leda till att pipelinen utlöses för alla uppdateringar av den grenen. Om du vill förhindra det här beteendet kan du:

1. Redigera pipelinen i Azure Pipelines-användargränssnittet.
2. Gå till menyn Utlösare .
3. Välj Åsidosätt utlösaren för kontinuerlig integrering av YAML härifrån.
4. Ange vilka grenar som ska inkluderas eller exkluderas för utlösaren.

När du följer de här stegen ignoreras alla CI-utlösare som anges i YAML-filen.

Fel version

En fel version av YAML-filen används i pipelinen. Varför är det?

• För CI-utlösare utvärderas YAML-filen som finns i grenen som du pushar för att se om en CI-version ska köras.
• För PR-utlösare utvärderas YAML-filen som härrör från sammanslagning av käll- och målgrenarna för PR för att se om en PR-version ska köras.