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

YAML

Du skapar en ny pipeline genom att först välja en Bitbucket Cloud-lagringsplats och sedan en YAML-fil på den lagringsplatsen. Lagringsplatsen där YAML-filen finns kallas self lagringsplats. Som standard är det här lagringsplatsen som pipelinen bygger.

Du kan senare konfigurera din pipeline för att checka ut en annan lagringsplats eller flera lagringsplatser. Mer information om hur du gör detta finns i checkouten för flera lagringsplatser.

Klassisk

Du skapar en ny pipeline genom att först välja Bitbucket Cloud som lagringsplatstyp och sedan en av de lagringsplatser som du har åtkomst till.

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.

Authentication type	Pipelines körs med
1. OAuth	Din personliga Bitbucket-identitet
2. Användarnamn och lösenord	Din personliga Bitbucket-identitet

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.

Kommentar

Det maximala antalet Bitbucket-lagringsplatser som Azure DevOps Services-användargränssnittet kan läsa in är 2 000.

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.

YAML

YAML-pipelines konfigureras som standard med en CI-utlösare på alla grenar, såvida inte inställningen Inaktivera underförstådda YAML CI-utlösare , som introducerades i Azure DevOps sprint 227, är aktiverad. Inställningen Inaktivera underförstådda YAML CI-utlösare kan konfigureras på organisationsnivå eller på projektnivå. När inställningen Inaktivera underförstådd YAML CI-utlösare är aktiverad aktiveras inte CI-utlösare för YAML-pipelines om YAML-pipelinen inte har något trigger avsnitt. Inaktivera underförstådda YAML CI-utlösare är inte aktiverat som standard.

Grenar

Du kan styra vilka grenar som får CI-utlösare med en enkel syntax:

trigger:
- main
- releases/*

Du kan ange det fullständiga namnet på grenen (till exempel main) eller ett jokertecken (till exempel releases/*). Se Jokertecken för information om jokerteckensyntaxen.

Kommentar

Du kan inte använda variabler i utlösare eftersom variabler utvärderas vid körning (när utlösaren har utlösts).

Kommentar

Om du använder mallar för att skapa YAML-filer kan du bara ange utlösare i yaml-huvudfilen för pipelinen. Du kan inte ange utlösare i mallfilerna.

För mer komplexa utlösare som använder exclude eller batchmåste du använda den fullständiga syntaxen enligt följande exempel.

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

I exemplet ovan utlöses pipelinen om en ändring skickas till main eller till någon versionsgren. Det utlöses dock inte om en ändring görs i en versionsgren som börjar med old.

Om du anger en exclude sats utan en include sats motsvarar det att * ange i include -satsen.

Förutom att ange grennamn i branches listorna kan du även konfigurera utlösare baserat på taggar med hjälp av följande format:

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

Om du inte angav några utlösare och inställningen Inaktivera underförstådda YAML CI-utlösare inte är aktiverad är standardvärdet som om du skrev:

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

Viktigt!

När du anger en utlösare ersätter den den implicita standardutlösaren och endast push-överföring till grenar som uttryckligen har konfigurerats för att inkluderas utlöser en pipeline. Inkluderar bearbetas först och exkluderingar tas sedan bort från listan.

Batchbearbetning av CI-körningar

Om du ofta har många teammedlemmar som laddar upp ändringar kanske du vill minska antalet körningar som du startar. Om du anger batch till true, när en pipeline körs väntar systemet tills körningen har slutförts och startar sedan en annan körning med alla ändringar som ännu inte har skapats.

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

Kommentar

batch stöds inte i lagringsplatsens resursutlösare.

För att förtydliga det här exemplet kan vi säga att en push-överföring A orsakade att main pipelinen ovan kördes. När pipelinen körs skickas ytterligare push-överföring B och C sker till lagringsplatsen. Dessa uppdateringar startar inte nya oberoende körningar omedelbart. Men när den första körningen har slutförts skickas alla push-meddelanden tills den tidpunkten batchats ihop och en ny körning startas.

Kommentar

Om pipelinen har flera jobb och faser bör den första körningen fortfarande nå ett terminaltillstånd genom att slutföra eller hoppa över alla jobb och faser innan den andra körningen kan starta. Därför måste du vara försiktig när du använder den här funktionen i en pipeline med flera steg eller godkännanden. Om du vill batcha dina versioner i sådana fall rekommenderar vi att du delar upp CI/CD-processen i två pipelines – en för build (med batchbearbetning) och en för distributioner.

Sekvenser

Du kan ange vilka filsökvägar som ska inkluderas eller exkluderas.

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

När du anger sökvägar måste du uttryckligen ange grenar som ska utlösas om du använder Azure DevOps Server 2019.1 eller lägre. Du kan inte utlösa en pipeline med endast ett sökvägsfilter. Du måste också ha ett grenfilter, och de ändrade filerna som matchar sökvägsfiltret måste vara från en gren som matchar grenfiltret. Om du använder Azure DevOps Server 2020 eller senare kan du utelämna branches att filtrera på alla grenar tillsammans med sökvägsfiltret.

Jokertecken stöds för sökvägsfilter. Du kan till exempel inkludera alla sökvägar som matchar src/app/**/myapp*. Du kan använda jokertecken (**, *eller ?) när du anger sökvägsfilter.

• Sökvägar anges alltid i förhållande till lagringsplatsens rot.
• Om du inte anger sökvägsfilter inkluderas lagringsplatsens rotmapp implicit som standard.
• Om du exkluderar en sökväg kan du inte också inkludera den om du inte kvalificerar den till en djupare mapp. Om du till exempel exkluderar /tools kan du inkludera /tools/trigger-runs-on-these
• Ordningen på sökvägsfilter spelar ingen roll.
• Sökvägar i Git är skiftlägeskänsliga. Se till att använda samma skiftläge som de riktiga mapparna.
• Du kan inte använda variabler i sökvägar, eftersom variabler utvärderas vid körning (när utlösaren har utlösts).

Kommentar

För Bitbucket Cloud-lagringsplatser är användning av branches syntax det enda sättet att ange taggutlösare. Syntaxen tags: stöds inte för Bitbucket.

Avregistrera dig från CI

Inaktivera CI-utlösaren

Du kan välja bort CI-utlösare helt och hållet genom att trigger: noneange .

# A pipeline with no CI trigger
trigger: none

Viktigt!

När du skickar en ändring till en gren utvärderas YAML-filen i den grenen för att avgöra om en CI-körning ska startas.

Klassisk

Kommentar

Variabeln Build.SourceVersionMessage fungerar inte med Bitbucket-lagringsplatser när Batch ändras medan en version pågår .

Välj Aktivera kontinuerlig integrering på fliken Utlösare för att aktivera den här utlösaren om du vill att versionen ska köras när någon checkar in kod.

Batch-ändringar

Markera den här kryssrutan om du har många teammedlemmar som laddar upp ändringar ofta och vill minska antalet versioner som du kör. Om du väljer det här alternativet, när en version körs, väntar systemet tills körningen har slutförts och köar sedan en annan körning av alla ändringar som ännu inte har skapats.

Du kan batchändringar och skapa dem tillsammans.

Kommentar

Om du använder batchbearbetning med en YAML-pipeline i flera steg måste en körning nå ett terminaltillstånd innan nästa kan starta. Detta är ofta inte önskvärt eftersom en pipeline i flera steg kan gå igenom godkännanden och långvariga distributionssteg. I dessa fall rekommenderar vi att du följer någon av följande lösningar:

• använd inte batchbearbetning
• dela upp pipelinen i två separata pipelines – en för CI och en CD
• ange lämpliga villkor för steg för att hoppa över dem och få en körning att avslutas snabbt

Grenfilter

Du kan ange de grenar där du vill utlösa byggen. Om du vill använda jokertecken skriver du grenspecifikationen (till exempel features/modules/*) och trycker sedan på Retur.

Sökvägsfilter

Om din Git-lagringsplats finns i Azure Repos eller TFS kan du också ange sökvägsfilter för att minska den uppsättning filer som du vill utlösa en version.

Tips:

• Sökvägar anges alltid i förhållande till lagringsplatsens rot.
• Om du inte anger sökvägsfilter inkluderas lagringsplatsens rotmapp implicit som standard.
• Om du exkluderar en sökväg kan du inte också inkludera den om du inte kvalificerar den till en djupare mapp. Om du till exempel exkluderar /tools kan du inkludera /tools/trigger-runs-on-these
• Ordningen på sökvägsfilter spelar ingen roll.
• Sökvägar i Git är skiftlägeskänsliga. Se till att använda samma skiftläge som de riktiga mapparna.

Exempel

Du vill till exempel att bygget ska utlösas av ändringar i main och de flesta, men inte alla, av dina funktionsgrenar. Du vill inte heller att byggen ska utlösas av ändringar i filer i verktygsmappen.

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.

YAML

Grenar

Du kan ange målgrenarna när du verifierar dina pull-begäranden. Om du till exempel vill verifiera pull-begäranden som mål master och releases/*kan du använda följande pr utlösare.

pr:
- main
- releases/*

Den här konfigurationen startar en ny körning första gången en ny pull-begäran skapas och efter varje uppdatering som görs i pull-begäran.

Du kan ange det fullständiga namnet på grenen (till exempel master) eller ett jokertecken (till exempel releases/*).

Kommentar

Du kan inte använda variabler i utlösare eftersom variabler utvärderas vid körning (när utlösaren har utlösts).

Kommentar

Om du använder mallar för att skapa YAML-filer kan du bara ange utlösare i yaml-huvudfilen för pipelinen. Du kan inte ange utlösare i mallfilerna.

Varje ny körning skapar den senaste incheckningen från källgrenen för pull-begäran. Det här skiljer sig från hur Azure Pipelines skapar pull-begäranden på andra lagringsplatser (t.ex. Azure Repos eller GitHub), där sammanslagningsincheckningen skapas. Bitbucket exponerar tyvärr inte information om sammanslagningsincheckningen, som innehåller den sammanfogade koden mellan käll- och målgrenarna för pull-begäran.

Om inga pr utlösare visas i YAML-filen aktiveras validering av pull-begäranden automatiskt för alla grenar, som om du skrev följande pr utlösare. Den här konfigurationen utlöser ett bygge när en pull-begäran skapas och när incheckningar kommer in i källgrenen för en aktiv pull-begäran.

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

Viktigt!

När du anger en pr utlösare ersätter den den implicita pr standardutlösaren och endast push-överföring till grenar som uttryckligen har konfigurerats för att inkluderas utlöser en pipeline.

För mer komplexa utlösare som behöver exkludera vissa grenar måste du använda den fullständiga syntaxen enligt följande exempel.

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

Sekvenser

Du kan ange vilka filsökvägar som ska inkluderas eller exkluderas. Till exempel:

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

Tips:

• Jokertecken stöds inte med sökvägsfilter.
• Sökvägar anges alltid i förhållande till lagringsplatsens rot.
• Om du inte anger sökvägsfilter inkluderas lagringsplatsens rotmapp implicit som standard.
• Om du exkluderar en sökväg kan du inte också inkludera den om du inte kvalificerar den till en djupare mapp. Om du till exempel exkluderar /tools kan du inkludera /tools/trigger-runs-on-these
• Ordningen på sökvägsfilter spelar ingen roll.
• Sökvägar i Git är skiftlägeskänsliga. Se till att använda samma skiftläge som de riktiga mapparna.
• Du kan inte använda variabler i sökvägar, eftersom variabler utvärderas vid körning (när utlösaren har utlösts).

Flera PR-uppdateringar

Du kan ange om ytterligare uppdateringar av en pr ska avbryta pågående valideringskörningar för samma PR. Standardvärdet är true.

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

Avregistrera dig från PR-validering

Du kan välja bort validering av pull-begäran helt genom att pr: noneange .

# no PR triggers
pr: none

Mer information finns i PR-utlösare i YAML-schemat.

Kommentar

Om utlösaren pr inte utlöses kontrollerar du att du inte har åsidosättat YAML PR-utlösare i användargränssnittet.

Klassisk

Markera valideringsutlösaren för pull-begäran och markera kryssrutan Aktivera validering av pull-begäranden för att aktivera versioner av pull-begäranden.

Du kan ange grenar som ska inkluderas och exkluderas. Välj ett grennamn i den nedrullningsbara menyn och välj Inkludera eller Exkludera efter behov. För inkluderade grenar utlöses en version på varje push-överföring till en pull-begäran som riktar sig till den grenen.

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.