Bitbucket Cloud-opslagplaatsen bouwen

Azure DevOps Services

Azure Pipelines kan elke pull-aanvraag automatisch bouwen en valideren en doorvoeren naar uw Bitbucket Cloud-opslagplaats. In dit artikel wordt beschreven hoe u de integratie tussen Bitbucket Cloud en Azure Pipelines configureert.

Bitbucket en Azure Pipelines zijn twee onafhankelijke services die goed samen kunnen worden geïntegreerd. Uw Bitbucket Cloud-gebruikers krijgen niet automatisch toegang tot Azure Pipelines. U moet ze expliciet toevoegen aan Azure Pipelines.

Toegang tot Bitbucket-opslagplaatsen

YAML

U maakt een nieuwe pijplijn door eerst een Bitbucket Cloud-opslagplaats en vervolgens een YAML-bestand in die opslagplaats te selecteren. De opslagplaats waarin het YAML-bestand aanwezig is, wordt opslagplaats genoemd self . Dit is standaard de opslagplaats die door uw pijplijn wordt gebouwd.

U kunt uw pijplijn later configureren om een andere opslagplaats of meerdere opslagplaatsen te bekijken. Als u wilt weten hoe u dit doet, raadpleegt u het uitchecken van meerdere opslagplaatsen.

Klassiek

U maakt een nieuwe pijplijn door eerst Bitbucket Cloud te selecteren voor het type opslagplaats en vervolgens een van de opslagplaatsen waar u toegang toe hebt.

Azure Pipelines moet toegang krijgen tot uw opslagplaatsen om de code op te halen tijdens builds. Bovendien moet de gebruiker die de pijplijn instelt beheerderstoegang hebben tot Bitbucket, omdat die identiteit wordt gebruikt voor het registreren van een webhook in Bitbucket.

Er zijn twee verificatietypen voor het verlenen van Azure Pipelines-toegang tot uw Bitbucket Cloud-opslagplaatsen tijdens het maken van een pijplijn.

Authentication type	Pijplijnen worden uitgevoerd met
1. OAuth	Uw persoonlijke Bitbucket-identiteit
2. Gebruikersnaam en wachtwoord	Uw persoonlijke Bitbucket-identiteit

OAuth-verificatie

OAuth is het eenvoudigste verificatietype waarmee u aan de slag kunt voor opslagplaatsen in uw Bitbucket-account. Bitbucket-statusupdates worden uitgevoerd namens uw persoonlijke Bitbucket-identiteit. Als u pijplijnen wilt laten werken, moet de toegang tot uw opslagplaats actief blijven.

Als u OAuth wilt gebruiken, meldt u zich aan bij Bitbucket wanneer u hierom wordt gevraagd tijdens het maken van de pijplijn. Klik vervolgens op Autoriseren om te autoriseren met OAuth. Een OAuth-verbinding wordt opgeslagen in uw Azure DevOps-project voor later gebruik en wordt gebruikt in de pijplijn die wordt gemaakt.

Notitie

Het maximum aantal Bitbucket-opslagplaatsen dat de gebruikersinterface van Azure DevOps Services kan laden, is 2000.

Wachtwoordverificatie

Builds en Bitbucket-statusupdates worden uitgevoerd namens uw persoonlijke identiteit. Voor builds die blijven werken, moet de toegang tot uw opslagplaats actief blijven.

Als u een wachtwoordverbinding wilt maken, gaat u naar Serviceverbindingen in uw Azure DevOps-projectinstellingen. Maak een nieuwe Bitbucket-serviceverbinding en geef de gebruikersnaam en het wachtwoord op om verbinding te maken met uw Bitbucket Cloud-opslagplaats.

CI-triggers

Ci-triggers (continue integratie) zorgen ervoor dat een pijplijn wordt uitgevoerd wanneer u een update naar de opgegeven vertakkingen pusht of dat u opgegeven tags pusht.

YAML

YAML-pijplijnen worden standaard geconfigureerd met een CI-trigger op alle vertakkingen, tenzij de instelling impliciete YAML CI-trigger uitschakelen, geïntroduceerd in Azure DevOps sprint 227, is ingeschakeld. De instelling impliciete YAML CI-trigger uitschakelen kan worden geconfigureerd op organisatieniveau of op projectniveau. Wanneer de instelling impliciete YAML CI-trigger uitschakelen is ingeschakeld, worden CI-triggers voor YAML-pijplijnen niet ingeschakeld als de YAML-pijplijn geen sectie heeft trigger . Impliciete YAML CI-trigger uitschakelen is standaard niet ingeschakeld.

Vertakkingen

U kunt bepalen welke vertakkingen CI-triggers ophalen met een eenvoudige syntaxis:

trigger:
- main
- releases/*

U kunt de volledige naam van de vertakking opgeven (bijvoorbeeld main) of een jokerteken (bijvoorbeeld releases/*). Zie Jokertekens voor informatie over de jokertekensyntaxis .

Notitie

U kunt geen variabelen in triggers gebruiken, omdat variabelen tijdens runtime worden geëvalueerd (nadat de trigger is geactiveerd).

Notitie

Als u sjablonen gebruikt om YAML-bestanden te maken, kunt u alleen triggers opgeven in het hoofd-YAML-bestand voor de pijplijn. U kunt geen triggers opgeven in de sjabloonbestanden.

Voor complexere triggers die gebruikmaken exclude van of batchmoet u de volledige syntaxis gebruiken, zoals wordt weergegeven in het volgende voorbeeld.

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

In het bovenstaande voorbeeld wordt de pijplijn geactiveerd als een wijziging wordt gepusht naar main of naar een releases-vertakking. Deze wordt echter niet geactiveerd als er een wijziging wordt aangebracht in een releases-vertakking die begint met old.

Als u een exclude component zonder component include opgeeft, is deze gelijk aan het opgeven * in de include component.

Naast het opgeven van vertakkingsnamen in de branches lijsten, kunt u ook triggers configureren op basis van tags met behulp van de volgende indeling:

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

Als u geen triggers hebt opgegeven en de instelling impliciete YAML CI-trigger uitschakelen niet is ingeschakeld, is de standaardinstelling alsof u schreef:

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

Belangrijk

Wanneer u een trigger opgeeft, wordt de standaard impliciete trigger vervangen en wordt alleen gepusht naar vertakkingen die expliciet zijn geconfigureerd om te worden opgenomen, wordt een pijplijn geactiveerd. Insluitingen worden eerst verwerkt en vervolgens worden uitgesloten uit die lijst.

Ci-uitvoeringen batchverwerking

Als u veel teamleden hebt die wijzigingen vaak uploaden, kunt u het aantal uitvoeringen dat u start verminderen. Als u instelt batch op true, wanneer een pijplijn wordt uitgevoerd, wacht het systeem totdat de uitvoering is voltooid en wordt een andere uitvoering gestart met alle wijzigingen die nog niet zijn gebouwd.

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

Notitie

batch wordt niet ondersteund in resourcetriggers voor opslagplaatsen.

Om dit voorbeeld te verduidelijken, laten we zeggen dat een push A om de bovenstaande pijplijn uit te main voeren. Terwijl die pijplijn wordt uitgevoerd, worden er extra pushs uitgevoerd B en C deze in de opslagplaats uitgevoerd. Deze updates starten niet onmiddellijk nieuwe onafhankelijke uitvoeringen. Maar nadat de eerste uitvoering is voltooid, worden alle pushes totdat dat tijdstip wordt gebatcheerd en wordt een nieuwe uitvoering gestart.

Notitie

Als de pijplijn meerdere taken en fasen heeft, moet de eerste uitvoering nog steeds een terminalstatus bereiken door alle bijbehorende taken en fasen te voltooien of over te slaan voordat de tweede uitvoering kan worden gestart. Daarom moet u voorzichtig zijn bij het gebruik van deze functie in een pijplijn met meerdere fasen of goedkeuringen. Als u uw builds in dergelijke gevallen wilt batcheren, wordt u aangeraden uw CI/CD-proces op te splitsen in twee pijplijnen: één voor build (met batchverwerking) en één voor implementaties.

Paden

U kunt bestandspaden opgeven die moeten worden opgenomen of uitgesloten.

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

Wanneer u paden opgeeft, moet u expliciet vertakkingen opgeven waarop moet worden geactiveerd als u Azure DevOps Server 2019.1 of lager gebruikt. U kunt een pijplijn niet activeren met alleen een padfilter; u moet ook een vertakkingsfilter hebben en de gewijzigde bestanden die overeenkomen met het padfilter moeten afkomstig zijn van een vertakking die overeenkomt met het vertakkingsfilter. Als u Azure DevOps Server 2020 of hoger gebruikt, kunt u weglaten branches om te filteren op alle vertakkingen in combinatie met het padfilter.

Wilds-kaarten worden ondersteund voor padfilters. U kunt bijvoorbeeld alle paden opnemen die overeenkomen src/app/**/myapp*. U kunt jokertekens gebruiken (**of *?) bij het opgeven van padfilters).

• Paden worden altijd opgegeven ten opzichte van de hoofdmap van de opslagplaats.
• Als u geen padfilters instelt, wordt de hoofdmap van de opslagplaats impliciet opgenomen.
• Als u een pad uitsluit, kunt u het niet ook opnemen, tenzij u het in aanmerking komt voor een diepere map. Als u bijvoorbeeld /tools uitsluit, kunt u /tools/trigger-runs-on-these opnemen
• De volgorde van padfilters maakt niet uit.
• Paden in Git zijn hoofdlettergevoelig. Zorg ervoor dat u hetzelfde hoofdlettergebruik gebruikt als de echte mappen.
• U kunt geen variabelen in paden gebruiken, omdat variabelen tijdens runtime worden geëvalueerd (nadat de trigger is geactiveerd).

Notitie

Voor Bitbucket Cloud-opslagplaatsen is het gebruik van branches syntaxis de enige manier om tagtriggers op te geven. De tags: syntaxis wordt niet ondersteund voor Bitbucket.

Afmelden voor CI

De CI-trigger uitschakelen

U kunt zich volledig afmelden voor CI-triggers door op te trigger: nonegeven.

# A pipeline with no CI trigger
trigger: none

Belangrijk

Wanneer u een wijziging naar een vertakking pusht, wordt het YAML-bestand in die vertakking geëvalueerd om te bepalen of een CI-uitvoering moet worden gestart.

Klassiek

Notitie

De variabele Build.SourceVersionMessage werkt niet met Bitbucket-opslagplaatsen wanneer Batch wordt gewijzigd terwijl een build wordt uitgevoerd , is ingeschakeld.

Selecteer Continue integratie inschakelen op het tabblad Triggers om deze trigger in te schakelen als u wilt dat de build wordt uitgevoerd wanneer iemand code incheckt.

Batchwijzigingen

Schakel dit selectievakje in als er veel teamleden wijzigingen vaak uploaden en u het aantal builds dat u uitvoert wilt verminderen. Als u deze optie selecteert wanneer een build wordt uitgevoerd, wacht het systeem totdat de uitvoering is voltooid en wordt vervolgens een andere uitvoering van alle wijzigingen die nog niet zijn gebouwd, in de wachtrij geplaatst.

U kunt batchwijzigingen batchgewijs maken en deze samen bouwen.

Notitie

Als u batchverwerking met een YAML-pijplijn met meerdere fasen gebruikt, moet een uitvoering een terminalstatus bereiken voordat de volgende kan worden gestart. Dit is vaak niet wenselijk omdat een pijplijn met meerdere fasen goedkeuringen en langdurige implementatiefasen kan doorlopen. In deze gevallen wordt u aangeraden een van deze oplossingen te volgen:

• batchverwerking niet gebruiken
• de pijplijn splitsen in twee afzonderlijke pijplijnen: één voor CI en één CD
• de juiste voorwaarden instellen voor fasen om ze over te slaan en een uitvoering snel te beëindigen

Vertakkingsfilters

U kunt de vertakkingen opgeven waar u builds wilt activeren. Als u jokertekens wilt gebruiken, typt u de vertakkingsspecificatie (bijvoorbeeld features/modules/*) en drukt u op Enter.

Padfilters

Als uw Git-opslagplaats zich in Azure-opslagplaatsen of TFS bevindt, kunt u ook padfilters opgeven om de set bestanden te verminderen die u wilt activeren voor een build.

Tips:

• Paden worden altijd opgegeven ten opzichte van de hoofdmap van de opslagplaats.
• Als u geen padfilters instelt, wordt de hoofdmap van de opslagplaats impliciet opgenomen.
• Als u een pad uitsluit, kunt u het niet ook opnemen, tenzij u het in aanmerking komt voor een diepere map. Als u bijvoorbeeld /tools uitsluit, kunt u /tools/trigger-runs-on-these opnemen
• De volgorde van padfilters maakt niet uit.
• Paden in Git zijn hoofdlettergevoelig. Zorg ervoor dat u hetzelfde hoofdlettergebruik gebruikt als de echte mappen.

Opmerking

U wilt bijvoorbeeld dat uw build wordt geactiveerd door wijzigingen in main en de meeste, maar niet alle, van uw functie-vertakkingen. U wilt ook niet dat builds worden geactiveerd door wijzigingen in bestanden in de map hulpprogramma's.

CI overslaan voor afzonderlijke doorvoeringen

U kunt Azure Pipelines ook vertellen om het uitvoeren van een pijplijn over te slaan die normaal gesproken door een push wordt geactiveerd. [skip ci] Neem alleen het bericht of de beschrijving op van een van de doorvoeringen die deel uitmaken van een push en Azure Pipelines slaat het uitvoeren van CI voor deze push over. U kunt ook een van de volgende variaties gebruiken.

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

Het triggertype gebruiken in voorwaarden

Het is een veelvoorkomend scenario voor het uitvoeren van verschillende stappen, taken of fasen in uw pijplijn, afhankelijk van het type trigger waarmee de uitvoering is gestart. U kunt dit doen met behulp van de systeemvariabele Build.Reason. Voeg bijvoorbeeld de volgende voorwaarde toe aan uw stap, taak of fase om deze uit te sluiten van pull-validaties.

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

Gedrag van triggers wanneer nieuwe vertakkingen worden gemaakt

Het is gebruikelijk om meerdere pijplijnen voor dezelfde opslagplaats te configureren. U hebt bijvoorbeeld één pijplijn om de documenten voor uw app te bouwen en een andere om de broncode te bouwen. U kunt CI-triggers configureren met de juiste vertakkingsfilters en padfilters in elk van deze pijplijnen. U wilt bijvoorbeeld dat één pijplijn wordt geactiveerd wanneer u een update naar de docs map pusht en een andere die moet worden geactiveerd wanneer u een update naar uw toepassingscode pusht. In deze gevallen moet u weten hoe de pijplijnen worden geactiveerd wanneer een nieuwe vertakking wordt gemaakt.

Dit is het gedrag wanneer u een nieuwe vertakking (die overeenkomt met de vertakkingsfilters) naar uw opslagplaats pusht:

• Als uw pijplijn padfilters bevat, wordt deze alleen geactiveerd als de nieuwe vertakking wijzigingen bevat in bestanden die overeenkomen met dat padfilter.
• Als uw pijplijn geen padfilters heeft, wordt deze geactiveerd, zelfs als er geen wijzigingen in de nieuwe vertakking zijn.

Jokertekens

Wanneer u een vertakking, tag of pad opgeeft, kunt u een exacte naam of een jokerteken gebruiken. Jokertekens-patronen maken het * mogelijk om nul of meer tekens overeen te laten komen en ? één teken te vinden.

• Als u uw patroon * in een YAML-pijplijn start, moet u het patroon tussen aanhalingstekens laten teruglopen, zoals "*-releases".
• Voor vertakkingen en tags:
  • Er kan ergens in het patroon een jokerteken worden weergegeven.
• Voor paden:
  • In Azure DevOps Server 2022 en hoger, met inbegrip van Azure DevOps Services, kan een jokerteken overal in een padpatroon worden weergegeven en u kunt dit gebruiken * of ?.
  • In Azure DevOps Server 2020 en lager kunt u het laatste teken opnemen * , maar dit doet niets anders dan het opgeven van de mapnaam zelf. U mag niet * opnemen in het midden van een padfilter en u mag dit niet gebruiken?.

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

PR-triggers

Pull-aanvraagtriggers zorgen ervoor dat een pijplijn wordt uitgevoerd wanneer een pull-aanvraag wordt geopend met een van de opgegeven doelbranches of wanneer er updates worden uitgevoerd voor een dergelijke pull-aanvraag.

YAML

Vertakkingen

U kunt de doelbranches opgeven bij het valideren van uw pull-aanvragen. Als u bijvoorbeeld pull-aanvragen wilt valideren die zijn gericht master en releases/*, kunt u de volgende pr trigger gebruiken.

pr:
- main
- releases/*

Met deze configuratie wordt een nieuwe uitvoering gestart wanneer een nieuwe pull-aanvraag voor het eerst wordt gemaakt en na elke update die is aangebracht in de pull-aanvraag.

U kunt de volledige naam van de vertakking opgeven (bijvoorbeeld master) of een jokerteken (bijvoorbeeld releases/*).

Notitie

U kunt geen variabelen in triggers gebruiken, omdat variabelen tijdens runtime worden geëvalueerd (nadat de trigger is geactiveerd).

Notitie

Als u sjablonen gebruikt om YAML-bestanden te maken, kunt u alleen triggers opgeven in het hoofd-YAML-bestand voor de pijplijn. U kunt geen triggers opgeven in de sjabloonbestanden.

Elke nieuwe uitvoering bouwt de meest recente doorvoer vanuit de bronbranch van de pull-aanvraag. Dit verschilt van de manier waarop Azure Pipelines pull-aanvragen bouwt in andere opslagplaatsen (bijvoorbeeld Azure-opslagplaatsen of GitHub), waar de samenvoegdoorvoering wordt gebouwd. Helaas bevat Bitbucket geen informatie over de samenvoegdoorvoering, die de samengevoegde code bevat tussen de bron- en doelbranches van de pull-aanvraag.

Als er geen pr triggers worden weergegeven in uw YAML-bestand, worden validaties van pull-aanvragen automatisch ingeschakeld voor alle vertakkingen, alsof u de volgende pr trigger hebt geschreven. Deze configuratie activeert een build wanneer een pull-aanvraag wordt gemaakt en wanneer doorvoeringen in de bronbranch van een actieve pull-aanvraag binnenkomen.

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

Belangrijk

Wanneer u een pr trigger opgeeft, wordt de standaard impliciete pr trigger vervangen en wordt alleen gepusht naar vertakkingen die expliciet zijn geconfigureerd om te worden opgenomen, wordt een pijplijn geactiveerd.

Voor complexere triggers die bepaalde vertakkingen moeten uitsluiten, moet u de volledige syntaxis gebruiken, zoals wordt weergegeven in het volgende voorbeeld.

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

Paden

U kunt bestandspaden opgeven die moeten worden opgenomen of uitgesloten. Voorbeeld:

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

Tips:

• Jokertekens worden niet ondersteund met padfilters.
• Paden worden altijd opgegeven ten opzichte van de hoofdmap van de opslagplaats.
• Als u geen padfilters instelt, wordt de hoofdmap van de opslagplaats impliciet opgenomen.
• Als u een pad uitsluit, kunt u het niet ook opnemen, tenzij u het in aanmerking komt voor een diepere map. Als u bijvoorbeeld /tools uitsluit, kunt u /tools/trigger-runs-on-these opnemen
• De volgorde van padfilters maakt niet uit.
• Paden in Git zijn hoofdlettergevoelig. Zorg ervoor dat u hetzelfde hoofdlettergebruik gebruikt als de echte mappen.
• U kunt geen variabelen in paden gebruiken, omdat variabelen tijdens runtime worden geëvalueerd (nadat de trigger is geactiveerd).

Meerdere pull-aanvraagupdates

U kunt opgeven of extra updates voor een pull-aanvraag validatieuitvoeringen voor dezelfde pull-aanvraag moeten annuleren. De standaardwaarde is true.

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

Afmelden voor pull-aanvraagvalidatie

U kunt zich volledig afmelden voor validatie van pull-aanvragen door op te pr: nonegeven.

# no PR triggers
pr: none

Zie PULL-trigger in het YAML-schema voor meer informatie.

Notitie

Als uw pr trigger niet wordt geactiveerd, controleert u of u geen YAML PR-triggers hebt overschreven in de gebruikersinterface.

Klassiek

Schakel de validatietrigger voor pull-aanvragen in en schakel het selectievakje Validatie van pull-aanvragen inschakelen in om builds op pull-aanvragen in te schakelen.

U kunt vertakkingen opgeven die moeten worden opgenomen en uitgesloten. Selecteer een vertakkingsnaam in de vervolgkeuzelijst en selecteer Indien nodig Opnemen of Uitsluiten . Voor opgenomen vertakkingen wordt een build geactiveerd voor elke push naar een pull-aanvraag gericht op die vertakking.

Informatieve uitvoeringen

Een informatieve uitvoering geeft aan dat Azure DevOps de broncode van een YAML-pijplijn niet kan ophalen. Het ophalen van broncode vindt plaats als reactie op externe gebeurtenissen, bijvoorbeeld een gepushte doorvoer. Het gebeurt ook als reactie op interne triggers, bijvoorbeeld om te controleren of er codewijzigingen zijn en een geplande uitvoering starten of niet. Ophalen van broncode kan om meerdere redenen mislukken, waarbij vaak een aanvraagbeperking wordt aangevraagd door de provider van de Git-opslagplaats. Het bestaan van een informatieve uitvoering betekent niet noodzakelijkerwijs dat Azure DevOps de pijplijn gaat uitvoeren.

Een informatieve uitvoering ziet eruit in de volgende schermopname.

U kunt een informatieve uitvoering herkennen door de volgende kenmerken:

• Status is Canceled
• Duur is < 1s
• De uitvoeringsnaam bevat een van de volgende teksten:
  • 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.
• Run name bevat over het algemeen de BitBucket/GitHub-fout waardoor het laden van de YAML-pijplijn is mislukt
• Geen fasen / taken / stappen

Meer informatie over informatieve uitvoeringen.

Beperkingen

Azure Pipelines laadt maximaal 2000 vertakkingen uit een opslagplaats in vervolgkeuzelijsten in de Azure Devops-portal, bijvoorbeeld in de standaardvertakking voor handmatige en geplande builds , of wanneer u een vertakking kiest wanneer u handmatig een pijplijn uitvoert. Als u de gewenste vertakking niet in de lijst ziet, typt u de naam van de gewenste vertakking handmatig.

Veelgestelde vragen

Problemen met betrekking tot Bitbucket-integratie vallen in de volgende categorieën:

• Mislukte triggers: Mijn pijplijn wordt niet geactiveerd wanneer ik een update naar de opslagplaats push.
• Verkeerde versie: Mijn pijplijn wordt uitgevoerd, maar er wordt een onverwachte versie van de bron/YAML gebruikt.

Mislukte triggers

Ik heb zojuist een nieuwe YAML-pijplijn gemaakt met CI/PR-triggers, maar de pijplijn wordt niet geactiveerd.

Volg deze stappen om problemen met uw mislukte triggers op te lossen:

• Worden uw YAML CI- of PULL-triggers overschreven door pijplijninstellingen in de gebruikersinterface? Kies tijdens het bewerken van uw pijplijn ... en vervolgens Triggers.

  

  Controleer de YAML-trigger van hieruit negeren voor de typen triggers (continue integratie of validatie van pull-aanvragen) die beschikbaar zijn voor uw opslagplaats.

  

• Webhooks worden gebruikt om updates van Bitbucket naar Azure Pipelines te communiceren. Navigeer in Bitbucket naar de instellingen voor uw opslagplaats en ga vervolgens naar Webhooks. Controleer of de webhooks bestaan.

• Is uw pijplijn onderbroken of uitgeschakeld? Open de editor voor de pijplijn en selecteer Instellingen om te controleren. Als uw pijplijn is onderbroken of uitgeschakeld, werken triggers niet.

• Hebt u het YAML-bestand in de juiste vertakking bijgewerkt? Als u een update naar een vertakking pusht, bepaalt het YAML-bestand in diezelfde vertakking het CI-gedrag. Als u een update naar een bronbranch pusht, bepaalt het YAML-bestand dat het gevolg is van het samenvoegen van de bronbranch met de doelbranch het gedrag van de pull-aanvraag. Zorg ervoor dat het YAML-bestand in de juiste vertakking de benodigde CI- of PR-configuratie heeft.

• Hebt u de trigger correct geconfigureerd? Wanneer u een YAML-trigger definieert, kunt u zowel component opnemen als uitsluiten voor vertakkingen, tags en paden opgeven. Zorg ervoor dat de include-component overeenkomt met de details van uw doorvoer en dat de exclude-component deze niet uitsluit. Controleer de syntaxis voor de triggers en controleer of deze juist is.

• Hebt u variabelen gebruikt bij het definiëren van de trigger of de paden? Dat wordt niet ondersteund.

• Hebt u sjablonen gebruikt voor uw YAML-bestand? Als dit het geval is, moet u ervoor zorgen dat uw triggers zijn gedefinieerd in het hoofd-YAML-bestand. Triggers die in sjabloonbestanden zijn gedefinieerd, worden niet ondersteund.

• Hebt u de vertakkingen of paden waarnaar u uw wijzigingen hebt gepusht uitgesloten? Test door een wijziging naar een opgenomen pad in een opgenomen vertakking te pushen. Houd er rekening mee dat paden in triggers hoofdlettergevoelig zijn. Zorg ervoor dat u dezelfde case gebruikt als die van echte mappen bij het opgeven van de paden in triggers.

• Heb je net een nieuwe vertakking gepusht? Zo ja, dan start de nieuwe vertakking mogelijk geen nieuwe uitvoering. Zie de sectie 'Gedrag van triggers wanneer nieuwe vertakkingen worden gemaakt'.

Mijn CI- of PR-triggers werken prima. Maar ze werkten nu niet meer.

Voer eerst de stappen voor probleemoplossing in de vorige vraag uit. Voer vervolgens de volgende aanvullende stappen uit:

• Hebt u samenvoegingsconflicten in uw pull-aanvraag? Voor een pull-aanvraag die geen pijplijn heeft geactiveerd, opent u deze en controleert u of er een samenvoegingsconflict is opgetreden. Los het samenvoegingsconflict op.

• Ondervindt u een vertraging bij het verwerken van push- of pull-gebeurtenissen? U kunt dit meestal controleren door te zien of het probleem specifiek is voor één pijplijn of gebruikelijk is voor alle pijplijnen of opslagplaatsen in uw project. Als een push- of PULL-update naar een van de opslagplaatsen dit symptoom vertoont, kunnen er vertragingen optreden bij het verwerken van de updategebeurtenissen. Controleer of er een servicestoring op onze statuspagina optreedt. Als op de statuspagina een probleem wordt weergegeven, moet het team al aan het werk zijn. Controleer regelmatig de pagina op updates over het probleem.

Ik wil niet dat gebruikers de lijst met vertakkingen voor triggers overschrijven wanneer ze het YAML-bestand bijwerken. Hoe kan ik dat doen?

Gebruikers met machtigingen voor het bijdragen van code kunnen het YAML-bestand bijwerken en extra vertakkingen opnemen/uitsluiten. Als gevolg hiervan kunnen gebruikers hun eigen functie of gebruikersbranch opnemen in hun YAML-bestand en die update naar een functie of gebruikersbranch pushen. Dit kan ertoe leiden dat de pijplijn wordt geactiveerd voor alle updates voor die vertakking. Als u dit gedrag wilt voorkomen, kunt u het volgende doen:

1. Bewerk de pijplijn in de gebruikersinterface van Azure Pipelines.
2. Navigeer naar het menu Triggers .
3. Selecteer Hier de YAML-trigger voor continue integratie overschrijven.
4. Geef de vertakkingen op die moeten worden opgenomen of uitgesloten voor de trigger.

Wanneer u deze stappen uitvoert, worden eventuele CI-triggers die zijn opgegeven in het YAML-bestand genegeerd.

Verkeerde versie

Er wordt een verkeerde versie van het YAML-bestand gebruikt in de pijplijn. Waarom is dat?

• Voor CI-triggers wordt het YAML-bestand dat zich in de vertakking bevindt die u pusht geëvalueerd om te zien of een CI-build moet worden uitgevoerd.
• Voor PULL-triggers wordt het YAML-bestand dat voortvloeit uit het samenvoegen van de bron- en doelbranches van de pull-aanvraag geëvalueerd om te zien of een PULL-build moet worden uitgevoerd.