GitHub-opslagplaatsen bouwen

Azure DevOps Services

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

Als u geen gebruik hebt gemaakt van de integratie van pijplijnen met GitHub, volgt u de stappen in Uw eerste pijplijn maken. Ga terug naar dit artikel voor meer informatie over het configureren en aanpassen van de integratie tussen GitHub en Azure Pipelines.

Organisaties en gebruikers

GitHub en Azure Pipelines zijn twee onafhankelijke services die goed samen kunnen worden geïntegreerd. Elk van hen heeft een eigen organisatie en gebruikersbeheer. In deze sectie wordt aanbevolen hoe u de organisatie en gebruikers van GitHub repliceert naar Azure Pipelines.

Organisaties

De structuur van GitHub bestaat uit organisaties en gebruikersaccounts die opslagplaatsen bevatten. Raadpleeg de documentatie van GitHub.

De structuur van Azure DevOps bestaat uit organisaties die projecten bevatten. Zie De structuur van uw organisatie plannen.

Azure DevOps kan uw GitHub-structuur weerspiegelen met:

• Een DevOps-organisatie voor uw GitHub-organisatie of gebruikersaccount
• DevOps Projects voor uw GitHub-opslagplaatsen

Een identieke structuur instellen in Azure DevOps:

1. Maak een DevOps-organisatie met de naam van uw GitHub-organisatie of gebruikersaccount. Deze heeft een URL zoals https://dev.azure.com/your-organization.
2. Maak in de DevOps-organisatie projecten met de naam van uw opslagplaatsen. Ze hebben URL's zoals https://dev.azure.com/your-organization/your-repository.
3. Maak in het DevOps-project pijplijnen met de naam van de GitHub-organisatie en opslagplaats die ze bouwen, zoals your-organization.your-repository. Vervolgens is het duidelijk voor welke opslagplaatsen ze zijn bedoeld.

Na dit patroon hebben uw GitHub-opslagplaatsen en Azure DevOps Projects overeenkomende URL-paden. Voorbeeld:

Service	URL
GitHub	https://github.com/python/cpython
Azure DevOps	https://dev.azure.com/python/cpython

Gebruikers

Uw GitHub-gebruikers krijgen niet automatisch toegang tot Azure Pipelines. Azure Pipelines is niet op de hoogte van GitHub-identiteiten. Daarom is er geen manier om Azure Pipelines te configureren om gebruikers automatisch op de hoogte te stellen van een buildfout of een pull-validatiefout met behulp van hun GitHub-identiteit en e-mailadres. U moet expliciet nieuwe gebruikers maken in Azure Pipelines om GitHub-gebruikers te repliceren. Zodra u nieuwe gebruikers hebt gemaakt, kunt u hun machtigingen configureren in Azure DevOps om hun machtigingen in GitHub weer te geven. U kunt ook meldingen in DevOps configureren met behulp van hun DevOps-identiteit.

GitHub-organisatierollen

GitHub-organisatielidrollen zijn te vinden op https://github.com/orgs/your-organization/people (vervangen your-organization).

Ledenmachtigingen voor DevOps-organisaties vindt u op https://dev.azure.com/your-organization/_settings/security (vervang your-organization).

Rollen in een GitHub-organisatie en gelijkwaardige rollen in een Azure DevOps-organisatie worden hieronder weergegeven.

GitHub-organisatierol	Equivalent van DevOps-organisatie
Eigenaar	Lid van Project Collection Administrators
Factureringsbeheerder	Lid van Project Collection Administrators
Lid	Lid van Project Collection Valid Users. Standaard ontbreekt de groep Leden machtigingen voor het maken van nieuwe projecten. Als u de machtiging wilt wijzigen, stelt u de machtiging van Create new projects de groep in op Allowof maakt u een nieuwe groep met machtigingen die u nodig hebt.

GitHub-gebruikersaccountrollen

Een GitHub-gebruikersaccount heeft één rol, die eigendom is van het account.

Ledenmachtigingen voor DevOps-organisaties vindt u op https://dev.azure.com/your-organization/_settings/security (vervang your-organization).

De gitHub-gebruikersaccountrol wordt als volgt toegewezen aan de machtigingen van de DevOps-organisatie.

GitHub-gebruikersaccountrol	Equivalent van DevOps-organisatie
Eigenaar	Lid van Project Collection Administrators

Machtigingen voor GitHub-opslagplaats

Machtigingen voor GitHub-opslagplaatsen vindt u op https://github.com/your-organization/your-repository/settings/collaboration (vervangen your-organization en your-repository).

DevOps-projectmachtigingen vindt u op https://dev.azure.com/your-organization/your-project/_settings/security (vervangen your-organization en your-project).

Gelijkwaardige machtigingen tussen GitHub-opslagplaatsen en Azure DevOps Projects zijn als volgt.

Machtiging voor GitHub-opslagplaats	Equivalent van DevOps-project
Beheerder	Lid van Project Administrators
Write	Lid van Contributors
Read	Lid van Readers

Als uw GitHub-opslagplaats machtigingen verleent aan teams, kunt u overeenkomende teams maken in de Teams sectie van uw Azure DevOps-projectinstellingen. Voeg vervolgens de teams toe aan de bovenstaande beveiligingsgroepen, net als gebruikers.

Pijplijnspecifieke machtigingen

Als u machtigingen wilt verlenen aan gebruikers of teams voor specifieke pijplijnen in een DevOps-project, voert u de volgende stappen uit:

1. Ga naar de pagina Pijplijnen van het project (bijvoorbeeld https://dev.azure.com/your-organization/your-project/_build).
2. Selecteer de pijplijn waarvoor u specifieke machtigingen wilt instellen.
3. Selecteer Beveiliging in het contextmenu '...'.
4. Selecteer Toevoegen... om een specifieke gebruiker, team of groep toe te voegen en de machtigingen voor de pijplijn aan te passen.

Toegang tot GitHub-opslagplaatsen

YAML

U maakt een nieuwe pijplijn door eerst een GitHub-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 GitHub 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 hun builds te activeren en hun code op te halen tijdens builds.

Er zijn drie verificatietypen voor het verlenen van Azure Pipelines-toegang tot uw GitHub-opslagplaatsen tijdens het maken van een pijplijn.

Authentication type	Pijplijnen worden uitgevoerd met	Werkt met GitHub-controles
1. GitHub-app	De Identiteit van Azure Pipelines	Ja
2. OAuth	Uw persoonlijke GitHub-identiteit	Nee
3. Persoonlijk toegangstoken (PAT)	Uw persoonlijke GitHub-identiteit	Nee

Verificatie van GitHub-apps

De GitHub-app voor Azure Pipelines is het aanbevolen verificatietype voor pijplijnen voor continue integratie. Nadat u de GitHub-app in uw GitHub-account of -organisatie hebt geïnstalleerd, wordt uw pijplijn uitgevoerd zonder uw persoonlijke GitHub-identiteit te gebruiken. Builds en GitHub-statusupdates worden uitgevoerd met behulp van de Azure Pipelines-identiteit. De app werkt met GitHub Checks om resultaten voor build-, test- en codedekking weer te geven in GitHub.

Als u de GitHub-app wilt gebruiken, installeert u deze in uw GitHub-organisatie of gebruikersaccount voor sommige of alle opslagplaatsen. De GitHub-app kan worden geïnstalleerd en verwijderd van de startpagina van de app.

Na de installatie wordt de GitHub-app de standaardmethode voor verificatie naar GitHub (in plaats van OAuth) van Azure Pipelines wanneer er pijplijnen worden gemaakt voor de opslagplaatsen.

Als u de GitHub-app installeert voor alle opslagplaatsen in een GitHub-organisatie, hoeft u zich geen zorgen te maken over Azure Pipelines die massa-e-mailberichten verzenden of pijplijnen automatisch namens u instellen. Als alternatief voor het installeren van de app voor alle opslagplaatsen kunnen opslagplaatsbeheerders deze één voor één installeren voor afzonderlijke opslagplaatsen. Dit vereist meer werk voor beheerders, maar heeft geen voordeel of nadeel.

Benodigde machtigingen in GitHub

Voor de installatie van de GitHub-app van Azure Pipelines moet u de eigenaar of opslagplaatsbeheerder van de GitHub-organisatie zijn. Als u bovendien een pijplijn wilt maken voor een GitHub-opslagplaats met continue integratie- en pull-aanvraagtriggers, moet u de vereiste GitHub-machtigingen hebben geconfigureerd. Anders wordt de opslagplaats niet weergegeven in de lijst met opslagplaatsen tijdens het maken van een pijplijn. Afhankelijk van het verificatietype en het eigendom van de opslagplaats, moet u ervoor zorgen dat de juiste toegang is geconfigureerd.

• Als de opslagplaats zich in uw persoonlijke GitHub-account bevindt, installeert u de GitHub-app van Azure Pipelines in uw persoonlijke GitHub-account en kunt u deze opslagplaats weergeven bij het maken van de pijplijn in Azure Pipelines.

• Als de opslagplaats zich in het persoonlijke GitHub-account van iemand anders bevindt, moet de andere persoon de Azure Pipelines GitHub-app installeren in hun persoonlijke GitHub-account. U moet worden toegevoegd als samenwerker in de instellingen van de opslagplaats onder Samenwerkers. Accepteer de uitnodiging als samenwerker met behulp van de koppeling die naar u wordt verzonden. Zodra u dit hebt gedaan, kunt u een pijplijn voor die opslagplaats maken.

• Als de opslagplaats zich in een GitHub-organisatie bevindt die u bezit, installeert u de GitHub-app van Azure Pipelines in de GitHub-organisatie. U moet ook worden toegevoegd als samenwerker of uw team moet worden toegevoegd in de instellingen van de opslagplaats onder Samenwerkers en teams.

• Als de opslagplaats zich in een GitHub-organisatie bevindt die eigenaar is van iemand anders, moet een eigenaar van een GitHub-organisatie of opslagplaatsbeheerder de GitHub-app van Azure Pipelines in de organisatie installeren. U moet worden toegevoegd als samenwerker of uw team moet worden toegevoegd in de instellingen van de opslagplaats onder Samenwerkers en teams. Accepteer de uitnodiging als samenwerker met behulp van de koppeling die naar u wordt verzonden.

GitHub-app-machtigingen

De GitHub-app vraagt de volgende machtigingen aan tijdens de installatie:

Machtiging	Hoe Azure Pipelines de machtiging gebruikt
Toegang tot code schrijven	Alleen bij uw opzettelijke actie vereenvoudigt Azure Pipelines het maken van een pijplijn door een YAML-bestand door te voeren in een geselecteerde vertakking van uw GitHub-opslagplaats.
Leestoegang tot metagegevens	Azure Pipelines haalt GitHub-metagegevens op voor het weergeven van de opslagplaats, vertakkingen en problemen die zijn gekoppeld aan een build in de samenvatting van de build.
Lees- en schrijftoegang tot controles	Azure Pipelines leest en schrijft zijn eigen build-, test- en codedekkingsresultaten die moeten worden weergegeven in GitHub.
Lees- en schrijftoegang tot pull-aanvragen	Alleen bij uw opzettelijke actie vereenvoudigen Azure Pipelines het maken van een pijplijn door een pull-aanvraag te maken voor een YAML-bestand dat is doorgevoerd in een geselecteerde vertakking van uw GitHub-opslagplaats. Pijplijnen haalt metagegevens van aanvragen op om weer te geven in buildoverzichten die zijn gekoppeld aan pull-aanvragen.

Problemen met de installatie van GitHub-apps oplossen

GitHub kan een fout weergeven, zoals:

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

Dit betekent dat de GitHub-app waarschijnlijk al is geïnstalleerd voor uw organisatie. Wanneer u een pijplijn voor een opslagplaats in de organisatie maakt, wordt de GitHub-app automatisch gebruikt om verbinding te maken met GitHub.

Pijplijnen maken in meerdere Azure DevOps-organisaties en -projecten

Zodra de GitHub-app is geïnstalleerd, kunnen pijplijnen worden gemaakt voor de opslagplaatsen van de organisatie in verschillende Azure DevOps-organisaties en -projecten. Als u echter pijplijnen maakt voor één opslagplaats in meerdere Azure DevOps-organisaties, kunnen alleen de pijplijnen van de eerste organisatie automatisch worden geactiveerd door GitHub-doorvoeringen of pull-aanvragen. Handmatige of geplande builds zijn nog steeds mogelijk in secundaire Azure DevOps-organisaties.

OAuth-verificatie

OAuth is het eenvoudigste verificatietype waarmee u aan de slag kunt voor opslagplaatsen in uw persoonlijke GitHub-account. GitHub-statusupdates worden uitgevoerd namens uw persoonlijke GitHub-identiteit. Als u pijplijnen wilt laten werken, moet de toegang tot uw opslagplaats actief blijven. Sommige GitHub-functies, zoals Controles, zijn niet beschikbaar met OAuth en vereisen de GitHub-app.

Als u OAuth wilt gebruiken, selecteert u Kies een andere verbinding onder de lijst met opslagplaatsen tijdens het maken van een pijplijn. Selecteer vervolgens Autoriseren om u aan te melden bij GitHub en 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.

Benodigde machtigingen in GitHub

Als u een pijplijn wilt maken voor een GitHub-opslagplaats met continue integratie en pull-aanvraagtriggers, moet u de vereiste GitHub-machtigingen hebben geconfigureerd. Anders wordt de opslagplaats niet weergegeven in de lijst met opslagplaatsen tijdens het maken van een pijplijn. Afhankelijk van het verificatietype en het eigendom van de opslagplaats, moet u ervoor zorgen dat de juiste toegang is geconfigureerd.

• Als de opslagplaats zich in uw persoonlijke GitHub-account bevindt, moet u ten minste één keer verifiëren bij GitHub met OAuth met behulp van uw persoonlijke GitHub-accountreferenties. Dit kan worden gedaan in azure DevOps-projectinstellingen onder Pijplijnserviceverbindingen >> Nieuwe serviceverbinding > GitHub > Autoriseren. Ververleent Azure Pipelines hier toegang tot uw opslagplaatsen onder Machtigingen.

• Als de opslagplaats zich in het persoonlijke GitHub-account van iemand anders bevindt, moet de andere persoon zich ten minste één keer verifiëren bij GitHub met OAuth met behulp van hun persoonlijke GitHub-accountreferenties. Dit kan worden gedaan in azure DevOps-projectinstellingen onder Pijplijnserviceverbindingen >> Nieuwe serviceverbinding > GitHub > Autoriseren. De andere persoon moet Azure Pipelines hier toegang verlenen tot hun opslagplaatsen onder Machtigingen. U moet worden toegevoegd als samenwerker in de instellingen van de opslagplaats onder Samenwerkers. Accepteer de uitnodiging als samenwerker met behulp van de koppeling die naar u wordt verzonden.

• Als de opslagplaats zich in een GitHub-organisatie bevindt die u bezit, ten minste één keer, verifieert u zich bij GitHub met OAuth met behulp van uw persoonlijke Referenties voor uw GitHub-account. Dit kan worden gedaan in azure DevOps-projectinstellingen onder Pijplijnserviceverbindingen >> Nieuwe serviceverbinding > GitHub > Autoriseren. Ververleent Azure Pipelines hier toegang tot uw organisatie onder 'Toegang tot organisatie'. U moet worden toegevoegd als samenwerker of uw team moet worden toegevoegd in de instellingen van de opslagplaats onder Samenwerkers en teams.

• Als de opslagplaats zich in een GitHub-organisatie bevindt die iemand anders bezit, moet een eigenaar van een GitHub-organisatie ten minste één keer verifiëren bij GitHub met OAuth met behulp van hun persoonlijke GitHub-accountreferenties. Dit kan worden gedaan in azure DevOps-projectinstellingen onder Pijplijnserviceverbindingen >> Nieuwe serviceverbinding > GitHub > Autoriseren. De eigenaar van de organisatie moet Azure Pipelines hier toegang verlenen tot de organisatie onder Toegang tot de organisatie. U moet worden toegevoegd als samenwerker of uw team moet worden toegevoegd in de instellingen van de opslagplaats onder Samenwerkers en teams. Accepteer de uitnodiging als samenwerker met behulp van de koppeling die naar u wordt verzonden.

OAuth-toegang intrekken

Nadat u Azure Pipelines hebt gemachtigd om OAuth te gebruiken, om deze later in te trekken en verder gebruik te voorkomen, gaat u naar OAuth-apps in uw GitHub-instellingen. U kunt deze ook verwijderen uit de lijst met GitHub-serviceverbindingen in uw Azure DevOps-projectinstellingen.

Persoonlijke toegangstokenverificatie (PAT)

PAW's zijn in feite hetzelfde als OAuth, maar u kunt bepalen welke machtigingen worden verleend aan Azure Pipelines. Builds en GitHub-statusupdates worden uitgevoerd namens uw persoonlijke GitHub-identiteit. Voor builds die blijven werken, moet de toegang tot uw opslagplaats actief blijven.

Als u een PAT wilt maken, gaat u naar Persoonlijke toegangstokens in uw GitHub-instellingen. De vereiste machtigingen zijn repo, admin:repo_hooken read:useruser:email. Dit zijn dezelfde machtigingen die vereist zijn bij het gebruik van OAuth hierboven. Kopieer de gegenereerde PAT naar het klembord en plak deze in een nieuwe GitHub-serviceverbinding in uw Azure DevOps-projectinstellingen. Geef de serviceverbinding een naam na uw GitHub-gebruikersnaam voor toekomstige relevante overeenkomsten. Het is beschikbaar in uw Azure DevOps-project voor later gebruik bij het maken van pijplijnen.

Benodigde machtigingen in GitHub

Als u een pijplijn wilt maken voor een GitHub-opslagplaats met continue integratie en pull-aanvraagtriggers, moet u de vereiste GitHub-machtigingen hebben geconfigureerd. Anders wordt de opslagplaats niet weergegeven in de lijst met opslagplaatsen tijdens het maken van een pijplijn. Afhankelijk van het verificatietype en het eigendom van de opslagplaats, moet u ervoor zorgen dat de volgende toegang is geconfigureerd.

• Als de opslagplaats zich in uw persoonlijke GitHub-account bevindt, moet de PAT de vereiste toegangsbereiken hebben onder Persoonlijke toegangstokens: repo, admin:repo_hook, read:useren user:email.

• Als de opslagplaats zich in het persoonlijke GitHub-account van iemand anders bevindt, moet de PAT de vereiste toegangsbereiken hebben onder Persoonlijke toegangstokens: repo, admin:repo_hook, read:useren user:email. U moet worden toegevoegd als samenwerker in de instellingen van de opslagplaats onder Samenwerkers. Accepteer de uitnodiging als samenwerker met behulp van de koppeling die naar u wordt verzonden.

• Als de opslagplaats zich in een GitHub-organisatie bevindt die u bezit, moet de PAT de vereiste toegangsbereiken hebben onder Persoonlijke toegangstokens: repo, admin:repo_hook, read:useren user:email. U moet worden toegevoegd als samenwerker of uw team moet worden toegevoegd in de instellingen van de opslagplaats onder Samenwerkers en teams.

• Als de opslagplaats zich in een GitHub-organisatie bevindt die iemand anders bezit, moet de PAT de vereiste toegangsbereiken hebben onder Persoonlijke toegangstokens: repo, admin:repo_hook, read:useren user:email. U moet worden toegevoegd als samenwerker of uw team moet worden toegevoegd in de instellingen van de opslagplaats onder Samenwerkers en teams. Accepteer de uitnodiging als samenwerker met behulp van de koppeling die naar u wordt verzonden.

PAT-toegang intrekken

Nadat u Azure Pipelines hebt gemachtigd om een PAT te gebruiken, om deze later te verwijderen en verder gebruik te voorkomen, gaat u naar Persoonlijke toegangstokens in uw GitHub-instellingen. U kunt deze ook verwijderen uit de lijst met GitHub-serviceverbindingen in uw Azure DevOps-projectinstellingen.

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

Codes

Naast het opgeven van tags in de branches lijsten zoals beschreven in de vorige sectie, kunt u rechtstreeks tags opgeven die moeten worden opgenomen of uitgesloten:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Als u geen tagtriggers opgeeft, worden met tags standaard geen pijplijnen geactiveerd.

Belangrijk

Als u tags in combinatie met vertakkingsfilters opgeeft, wordt de trigger geactiveerd als het vertakkingsfilter tevreden is of als het tagfilter is voldaan. Als een gepushte tag bijvoorbeeld voldoet aan het vertakkingsfilter, wordt de pijplijn geactiveerd, zelfs als de tag wordt uitgesloten door het tagfilter, omdat de push tevreden is met het vertakkingsfilter.

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

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 main 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 main) 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.

GitHub maakt een nieuwe ref wanneer een pull-aanvraag wordt gemaakt. De verw verwijst naar een samenvoegdoorvoering, de samengevoegde code tussen de bron- en doelvertakkingen van de pull-aanvraag. Met de pull-validatiepijplijn wordt de doorvoer gebouwd waarnaar deze verw verwijst. Dit betekent dat het YAML-bestand dat wordt gebruikt om de pijplijn uit te voeren, ook een samenvoeging is tussen de bron en de doelbranch. Als gevolg hiervan kunnen de wijzigingen die u aanbrengt in het YAML-bestand in de bronbranch van de pull-aanvraag het gedrag overschrijven dat is gedefinieerd door het YAML-bestand in de doelbranch.

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 met een subset vertakkingen opgeeft, wordt een pijplijn alleen geactiveerd wanneer updates naar die vertakkingen worden gepusht.

Voor complexere triggers die bepaalde vertakkingen moeten uitsluiten, moet u de volledige syntaxis gebruiken, zoals wordt weergegeven in het volgende voorbeeld. In dit voorbeeld worden pull-aanvragen gevalideerd dat doel main of releases/* en de vertakking releases/old* wordt uitgesloten.

# 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:

• Azure Pipelines plaatst een neutrale status terug naar GitHub wanneer wordt besloten geen validatiebuild uit te voeren vanwege een uitsluitingsregel voor paden. Dit biedt een duidelijke richting naar GitHub die aangeeft dat Azure Pipelines de verwerking heeft voltooid. Zie Post-neutrale status naar GitHub wanneer een build wordt overgeslagen voor meer informatie.
• Jokertekens worden nu 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).
• Azure Pipelines plaatst een neutrale status terug naar GitHub wanneer wordt besloten geen validatiebuild uit te voeren vanwege een uitsluitingsregel voor paden.

Meerdere pull-aanvraagupdates

U kunt opgeven of meer 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

Validatie van concept-pull-aanvraag

Standaard worden pull-aanvragen geactiveerd voor concept pull-aanvragen en pull-aanvragen die gereed zijn voor beoordeling. Als u triggers voor pull-aanvragen voor concept-pull-aanvragen wilt uitschakelen, stelt u de drafts eigenschap in op false.

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

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, volgt u de stappen voor probleemoplossing in de veelgestelde vragen.

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.

Als u een open pull-aanvraag hebt en u wijzigingen naar de bronbranch pusht, kunnen meerdere pijplijnen worden uitgevoerd:

• De pijplijnen met een PULL-trigger op de doelbranch worden uitgevoerd op de samenvoegdoorvoering (de samengevoegde code tussen de bron- en doelbranches van de pull-aanvraag), ongeacht of er push-doorvoeringen bestaan waarvan de berichten of beschrijvingen bestaan [skip ci] (of een van de varianten).
• De pijplijnen die worden geactiveerd door wijzigingen in de bronbranch van de pull-aanvraag, als er geen gepushte doorvoeringen zijn waarvan de berichten of beschrijvingen (of een van de varianten ervan) bevatten [skip ci] . Als ten minste één gepushte doorvoer bevat [skip ci], worden de pijplijnen niet uitgevoerd.

Nadat u de pull-aanvraag hebt samengevoegd, worden in Azure Pipelines de CI-pijplijnen uitgevoerd die worden geactiveerd door pushes naar de doelbranch, als het bericht of de beschrijving van de samenvoegingsdoorvoering geen (of een van de varianten) bevat [skip ci] .

Beveiligde branches

U kunt een validatiebuild uitvoeren met elke doorvoer- of pull-aanvraag die gericht is op een vertakking, en zelfs voorkomen dat pull-aanvragen worden samengevoegd totdat een validatie-build slaagt.

Als u verplichte validatie-builds wilt configureren voor een GitHub-opslagplaats, moet u de eigenaar zijn, een samenwerker met de Beheer rol of een Lid van de GitHub-organisatie met de rol Schrijven.

1. Maak eerst een pijplijn voor de opslagplaats en bouw deze ten minste één keer, zodat de status ervan wordt gepost op GitHub, waardoor GitHub op de hoogte wordt gesteld van de naam van de pijplijn.

2. Volg vervolgens de documentatie van GitHub voor het configureren van beveiligde vertakkingen in de instellingen van de opslagplaats.

   Selecteer voor de statuscontrole de naam van uw pijplijn in de lijst Statuscontroles .

   

Belangrijk

Als uw pijplijn niet wordt weergegeven in deze lijst, controleert u het volgende:

• U gebruikt Verificatie van GitHub-apps
• Uw pijplijn heeft in de afgelopen week minstens één keer uitgevoerd

Bijdragen van externe bronnen

Als uw GitHub-opslagplaats open source is, kunt u uw Azure DevOps-project openbaar maken, zodat iedereen de buildresultaten, logboeken en testresultaten van uw pijplijn kan bekijken zonder u aan te melden. Wanneer gebruikers buiten uw organisatie uw opslagplaats splitsen en pull-aanvragen indienen, kunnen ze de status van builds bekijken die deze pull-aanvragen automatisch valideren.

Houd rekening met de volgende overwegingen bij het gebruik van Azure Pipelines in een openbaar project bij het accepteren van bijdragen van externe bronnen.

• Toegangsbeperkingen
• Bijdragen van forks valideren
• Belangrijke beveiligingsoverwegingen

Toegangsbeperkingen

Houd rekening met de volgende toegangsbeperkingen wanneer u pijplijnen uitvoert in openbare Azure DevOps-projecten:

• Geheimen: geheimen die zijn gekoppeld aan uw pijplijn, worden standaard niet beschikbaar gesteld voor pull-aanvraagvalidaties van forks. Zie Bijdragen van forks valideren.
• Toegang tussen projecten: alle pijplijnen in een openbaar Azure DevOps-project worden uitgevoerd met een toegangstoken dat beperkt is tot het project. Pijplijnen in een openbaar project hebben alleen toegang tot resources zoals buildartefacten of testresultaten binnen het project en niet in andere projecten van de Azure DevOps-organisatie.
• Azure Artifacts-pakketten: Als uw pijplijnen toegang nodig hebben tot pakketten van Azure Artifacts, moet u expliciet toestemming verlenen aan het Project Build Service-account om toegang te krijgen tot de pakketfeeds.

Bijdragen van forks

Belangrijk

Deze instellingen zijn van invloed op de beveiliging van uw pijplijn.

Wanneer u een pijplijn maakt, wordt deze automatisch geactiveerd voor pull-aanvragen van forks van uw opslagplaats. U kunt dit gedrag wijzigen, zorgvuldig overwegen hoe dit van invloed is op de beveiliging. Ga als volgt te werk om dit gedrag in of uit te schakelen:

1. Ga naar uw Azure DevOps-project. Selecteer Pijplijnen, zoek uw pijplijn en selecteer Bewerken.
2. Selecteer het tabblad Triggers . Nadat u de pull-aanvraagtrigger hebt ingeschakeld, schakelt u het selectievakje Pull-aanvragen samenstellen uit forks van deze opslagplaats in of uit.

Bij GitHub-pijplijnen worden geheimen die zijn gekoppeld aan uw build-pijplijn standaard niet beschikbaar gesteld voor pull-aanvraagbuilds van forks. Deze geheimen zijn standaard ingeschakeld met GitHub Enterprise Server-pijplijnen. Geheimen zijn onder andere:

• Een beveiligingstoken met toegang tot uw GitHub-opslagplaats.
• Deze items, als uw pijplijn deze gebruikt:
  • Serviceverbindingsreferenties
  • Bestanden uit de beveiligde bestandenbibliotheek
  • Variabelen bouwen die zijn gemarkeerd als geheim

Als u deze voorzorgsmaatregel voor GitHub-pijplijnen wilt omzeilen, schakelt u het selectievakje Geheimen beschikbaar maken voor builds van forks in. Houd rekening met het effect van deze instelling op beveiliging.

Notitie

Wanneer u fork-builds inschakelt voor toegang tot geheimen, beperkt Azure Pipelines standaard het toegangstoken dat wordt gebruikt voor fork-builds. Het heeft beperktere toegang tot open resources dan een normaal toegangstoken. Als u fork-builds dezelfde machtigingen wilt geven als gewone builds, schakelt u de fork-builds in met dezelfde machtigingen als de normale builds-instelling .

Zie Opslagplaatsbeveiliging - Forks voor meer informatie.

U kunt centraal definiëren hoe pijplijnen pull-aanvragen bouwen vanuit geforkte GitHub-opslagplaatsen met behulp van pull-aanvragen beperken vanuit het besturingselement voor gesplitste GitHub-opslagplaatsen . Het is beschikbaar op organisatie- en projectniveau. U hebt de volgende keuzen:

• Pull-aanvragen uit forked-opslagplaatsen uitschakelen
• Pull-aanvragen veilig bouwen vanuit geforkte opslagplaatsen
• Regels aanpassen voor het bouwen van pull-aanvragen vanuit geforkte opslagplaatsen

Vanaf Sprint 229, om de beveiliging van uw pijplijnen te verbeteren, worden met Azure Pipelines geen pull-aanvragen meer automatisch gebouwd vanuit geforkte GitHub-opslagplaatsen. Voor nieuwe projecten en organisaties is de standaardwaarde voor het beperken van pull-aanvragen voor het bouwen van pull-aanvragen van forked GitHub-opslagplaatsen uitschakelen vanuit geforkte opslagplaatsen.

Wanneer u de optie Pull-aanvragen voor veilig bouwen kiest uit geforkte opslagplaatsen, kunnen alle pijplijnen, organisatie of projectbreed geen geheimen beschikbaar maken voor builds van pull-aanvragen vanuit geforkte opslagplaatsen, kunnen deze builds niet dezelfde machtigingen hebben als normale builds en moeten worden geactiveerd door een pull-aanvraagopmerking. Projecten kunnen nog steeds besluiten om pijplijnen niet toe te staan dergelijke PULL's te bouwen.

Wanneer u de optie Aanpassen kiest, kunt u definiëren hoe u de pijplijninstellingen kunt beperken. U kunt er bijvoorbeeld voor zorgen dat voor alle pijplijnen een opmerking is vereist om een pull-aanvraag te maken vanuit een vervalste GitHub-opslagplaats, wanneer de pull-aanvraag deel uitmaakt van niet-teamleden en niet-inzenders. U kunt er echter voor kiezen om geheimen beschikbaar te maken voor dergelijke builds. Projecten kunnen besluiten om pijplijnen niet toe te staan dergelijke PULL's te bouwen of om ze veilig te bouwen, of nog meer beperkende instellingen te hebben dan op organisatieniveau is opgegeven.

Het besturingselement is uitgeschakeld voor bestaande organisaties. Vanaf september 2023 hebben nieuwe organisaties pull-aanvragen veilig gemaakt vanuit geforkte opslagplaatsen die standaard zijn ingeschakeld.

Belangrijke beveiligingsoverwegingen

Een GitHub-gebruiker kan uw opslagplaats splitsen, wijzigen en een pull-aanvraag maken om wijzigingen in uw opslagplaats voor te stellen. Deze pull-aanvraag kan schadelijke code bevatten die moet worden uitgevoerd als onderdeel van uw geactiveerde build. Dergelijke code kan op de volgende manieren schade veroorzaken:

• Geheimen uit uw pijplijn lekken. Als u dit risico wilt beperken, schakelt u het selectievakje Geheimen beschikbaar maken voor builds van forks niet in als uw opslagplaats openbaar of niet-vertrouwde gebruikers pull-aanvragen kunnen indienen die automatisch builds activeren. Deze optie is standaard uitgeschakeld.

• Maak inbreuk op de computer waarop de agent wordt uitgevoerd om code of geheimen van andere pijplijnen te stelen. U kunt dit als volgt verhelpen:

  • Gebruik een door Microsoft gehoste agentgroep om pull-aanvragen van forks te bouwen. Door Microsoft gehoste agentmachines worden onmiddellijk verwijderd nadat ze een build hebben voltooid, dus er is geen blijvende impact als ze worden aangetast.

  • Als u een zelf-hostende agent moet gebruiken, slaat u geen geheimen op of voert u andere builds en releases uit die gebruikmaken van geheimen op dezelfde agent, tenzij uw opslagplaats privé is en u pull-aanvraagmakers vertrouwt.

Opmerkingentriggers

Samenwerkers van opslagplaatsen kunnen opmerkingen maken bij een pull-aanvraag om handmatig een pijplijn uit te voeren. Hier volgen enkele veelvoorkomende redenen waarom u dit mogelijk wilt doen:

• Mogelijk wilt u geen pull-aanvragen van onbekende gebruikers automatisch maken totdat hun wijzigingen kunnen worden gecontroleerd. U wilt dat een van uw teamleden eerst hun code controleert en vervolgens de pijplijn uitvoert. Dit wordt vaak gebruikt als een beveiligingsmaatregel bij het bouwen van code uit geforkte opslagplaatsen.
• Mogelijk wilt u een optioneel testpakket of nog een validatiebuild uitvoeren.

Als u opmerkingentriggers wilt inschakelen, moet u de volgende twee stappen uitvoeren:

1. Schakel pull-aanvraagtriggers in voor uw pijplijn en zorg ervoor dat u de doelbranch niet hebt uitgesloten.
2. Bewerk uw pijplijn in de webportal van Azure Pipelines en kies Meer acties, Triggers. Schakel vervolgens onder Validatie van pull-aanvraag de opmerking van een teamlid vereisen in voordat u een pull-aanvraag maakt.
   • Kies Bij alle pull-aanvragen om de opmerking van een teamlid te vereisen voordat u een pull-aanvraag maakt. Met deze werkstroom controleert een teamlid de pull-aanvraag en activeert de build met een opmerking zodra de pull-aanvraag als veilig wordt beschouwd.
   • Kies Alleen voor pull-aanvragen van niet-teamleden om alleen de opmerking van een teamlid te vereisen wanneer een pull-aanvraag wordt gedaan door een niet-teamlid. In deze werkstroom heeft een teamlid geen beoordeling van een secundair teamlid nodig om een build te activeren.

Met deze twee wijzigingen wordt de validatie van pull-aanvragen niet automatisch geactiveerd, tenzij alleen pull-aanvragen van niet-teamleden zijn geselecteerd en de pull-aanvraag wordt gemaakt door een teamlid. Alleen eigenaren van opslagplaatsen en samenwerkers met de machtiging Schrijven kunnen de build activeren door opmerkingen te maken bij de pull-aanvraag met /AzurePipelines run of /AzurePipelines run <pipeline-name>.

De volgende opdrachten kunnen worden uitgegeven aan Azure Pipelines in opmerkingen:

Opdracht	Resultaat
/AzurePipelines help	Help weergeven voor alle ondersteunde opdrachten.
/AzurePipelines help <command-name>	Help weergeven voor de opgegeven opdracht.
/AzurePipelines run	Voer alle pijplijnen uit die zijn gekoppeld aan deze opslagplaats en waarvan de triggers deze pull-aanvraag niet uitsluiten.
/AzurePipelines run <pipeline-name>	Voer de opgegeven pijplijn uit, tenzij de triggers deze pull-aanvraag uitsluiten.

Notitie

Voor kortheid kunt u opmerkingen maken met behulp /azp van in plaats van /AzurePipelines.

Belangrijk

Antwoorden op deze opdrachten worden alleen weergegeven in de pull-aanvraagdiscussie als uw pijplijn gebruikmaakt van de GitHub-app van Azure Pipelines.

Problemen met triggers voor opmerkingen bij pull-aanvragen oplossen

Als u over de benodigde opslagplaatsmachtigingen beschikt, maar pijplijnen niet worden geactiveerd door uw opmerkingen, moet u ervoor zorgen dat uw lidmaatschap openbaar is in de organisatie van de opslagplaats of u kunt uzelf rechtstreeks toevoegen als samenwerker van de opslagplaats. Pijplijnen kunnen geen leden van een privéorganisatie zien, tenzij ze directe medewerkers zijn of deel uitmaken van een team dat een directe samenwerker is. U kunt hier het lidmaatschap van uw GitHub-organisatie wijzigen van privé naar openbaar (vervang door Your-Organization de naam van uw organisatie): https://github.com/orgs/Your-Organization/people.

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.

Uitchecken

Wanneer een pijplijn wordt geactiveerd, haalt Azure Pipelines uw broncode op uit de Git-opslagplaats van Azure-opslagplaatsen. U kunt verschillende aspecten van hoe dit gebeurt beheren.

Notitie

Wanneer u een uitcheckstap in uw pijplijn opneemt, voeren we de volgende opdracht uit: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1 Als dit niet aan uw behoeften voldoet, kunt u ervoor kiezen om ingebouwde betaling checkout: none uit te sluiten en vervolgens een scripttaak te gebruiken om uw eigen betaling uit te voeren.

Voorkeursversie van Git

De Windows-agent wordt geleverd met een eigen exemplaar van Git. Als u liever uw eigen Git opgeeft in plaats van de meegeleverde kopie te gebruiken, stelt u deze in System.PreferGitFromPathtrueop . Deze instelling geldt altijd voor niet-Windows-agents.

Pad naar uitchecken

YAML

Als u één opslagplaats uitcheckt, wordt uw broncode standaard uitgecheckt in een map met de naam s. Voor YAML-pijplijnen kunt u dit wijzigen door checkout een path. Het opgegeven pad is relatief ten $(Agent.BuildDirectory)opzichte van . Bijvoorbeeld: als de waarde van het uitcheckpad dat is mycustompath en $(Agent.BuildDirectory) is C:\agent\_work\1, wordt de broncode uitgecheckt naar C:\agent\_work\1\mycustompath.

Als u meerdere checkout stappen gebruikt en meerdere opslagplaatsen uitcheckt en niet expliciet de map opgeeft met behulp pathvan, wordt elke opslagplaats in een submap met de naam van s de opslagplaats geplaatst. Als u bijvoorbeeld twee opslagplaatsen met de naam tools uitcheckt en code, wordt de broncode uitgecheckt naar C:\agent\_work\1\s\tools en C:\agent\_work\1\s\code.

Houd er rekening mee dat de waarde van het uitcheckpad niet kan worden ingesteld om de bovenstaande mapniveaus $(Agent.BuildDirectory)op te halen, dus path\..\anotherpath resulteert dit in een geldig betalingspad (dat wil C:\agent\_work\1\anotherpathweten), maar een waarde zoals ..\invalidpath niet (dat wil C:\agent\_work\invalidpathgezegd).

U kunt de path instelling configureren in de stap Uitchecken van uw pijplijn.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Klassiek

Deze instelling kan niet worden geconfigureerd in de klassieke editor. Uw broncode wordt uitgecheckt naar een map met de naam s, die relatief is ten $(Agent.BuildDirectory)opzichte van . Bijvoorbeeld: als $(Agent.BuildDirectory) dat het is C:\agent\_work\1, wordt de broncode uitgecheckt in C:\agent\_work\1\mycustompath.

Submodules

YAML

U kunt de submodules instelling configureren in de stap Uitchecken van uw pijplijn als u bestanden wilt downloaden uit submodules.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Klassiek

U kunt de instelling Submodules configureren vanuit de eigenschappen van de taak Bronnen ophalen in uw pijplijn als u bestanden uit submodules wilt downloaden.

Met de build-pijplijn worden uw Git-submodules uitgecheckt zolang ze:

• Niet-geverifieerd: een openbare, niet-geverifieerde opslagplaats zonder referenties die nodig zijn om te klonen of op te halen.

• Geverifieerde:

  • Dit is opgenomen in hetzelfde project als de Git-opslagplaats voor Azure-opslagplaatsen die hierboven is opgegeven. Dezelfde referenties die door de agent worden gebruikt om de bronnen op te halen uit de hoofdopslagplaats, worden ook gebruikt om de bronnen voor submodules op te halen.

  • Toegevoegd met behulp van een URL ten opzichte van de hoofdopslagplaats. Bijvoorbeeld

    • Deze wordt uitgecheckt: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      In dit voorbeeld verwijst de submodule naar een opslagplaats (FabrikamFiber) in dezelfde Azure DevOps-organisatie, maar in een ander project (FabrikamFiberProject). Dezelfde referenties die door de agent worden gebruikt om de bronnen op te halen uit de hoofdopslagplaats, worden ook gebruikt om de bronnen voor submodules op te halen. Hiervoor moet het toegangstoken voor de taak toegang hebben tot de opslagplaats in het tweede project. Als u het toegangstoken voor taken hebt beperkt, zoals uitgelegd in de bovenstaande sectie, kunt u dit niet doen. U kunt het toegangstoken voor de taak toestaan om toegang te krijgen tot de opslagplaats in het tweede project door (a) expliciet toegang te verlenen tot het serviceaccount voor projectbuild in het tweede project of (b) met behulp van toegangstokens binnen het bereik van verzamelingen in plaats van tokens met projectbereik voor de hele organisatie. Zie Access-opslagplaatsen, artefacten en andere resources voor meer informatie over deze opties en de gevolgen voor de beveiliging.

    • Deze zou niet worden uitgecheckt: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternatief voor het gebruik van de optie Uitchecken-submodules

In sommige gevallen kunt u de optie Submodules uitchecken niet gebruiken. Mogelijk hebt u een scenario waarin een andere set referenties nodig is voor toegang tot de submodules. Dit kan bijvoorbeeld gebeuren als uw hoofdopslagplaats en submoduleopslagplaatsen niet zijn opgeslagen in dezelfde Azure DevOps-organisatie, of als uw taaktoegangstoken geen toegang heeft tot de opslagplaats in een ander project.

Als u de optie Submodules uitchecken niet kunt gebruiken, kunt u in plaats daarvan een aangepaste scriptstap gebruiken om submodules op te halen. Haal eerst een persoonlijk toegangstoken (PAT) op en voorvoegsel met pat:. Vervolgens codeerde base64 deze voorvoegseltekenreeks om een basisverificatietoken te maken. Voeg tot slot dit script toe aan uw pijplijn:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Vervang '<BASE64_ENCODED_STRING>' door de tekenreeks 'pat:token' die is gecodeerd met Base64.

Gebruik een geheime variabele in uw project of build-pijplijn om het basisverificatietoken op te slaan dat u hebt gegenereerd. Gebruik deze variabele om het geheim in de bovenstaande Git-opdracht te vullen.

Notitie

V: Waarom kan ik geen Git-referentiebeheer voor de agent gebruiken?A: Het opslaan van de submodulereferenties in een Git-referentiebeheerder die is geïnstalleerd op uw privé-buildagent is meestal niet effectief, omdat de referentiebeheerder u mogelijk vraagt om de referenties opnieuw in te voeren wanneer de submodule wordt bijgewerkt. Dit is niet wenselijk tijdens geautomatiseerde builds wanneer gebruikersinteractie niet mogelijk is.

Tags synchroniseren

Belangrijk

De functie synchronisatietags wordt ondersteund in Azure Repos Git met Azure DevOps Server 2022.1 en hoger.

De stap uitchecken maakt gebruik van de optie bij het --tags ophalen van de inhoud van een Git-opslagplaats. Dit zorgt ervoor dat de server alle tags en alle objecten ophaalt waarnaar deze tags worden verwezen. Dit verhoogt de tijd voor het uitvoeren van de taak in een pijplijn, met name als u een grote opslagplaats met een aantal tags hebt. Bovendien synchroniseert de kassastap tags zelfs wanneer u de ondiepe ophaaloptie inschakelt, waardoor het doel mogelijk wordt verslagen. Om de hoeveelheid opgehaalde of opgehaalde gegevens uit een Git-opslagplaats te verminderen, heeft Microsoft een nieuwe optie toegevoegd om het gedrag van synchronisatietags te beheren. Deze optie is zowel beschikbaar in klassieke als YAML-pijplijnen.

Of tags moeten worden gesynchroniseerd bij het uitchecken van een opslagplaats, kan worden geconfigureerd in YAML door de eigenschap in te fetchTags stellen en in de gebruikersinterface door de instelling Labels synchroniseren te configureren.

YAML

U kunt de fetchTags instelling configureren in de stap Uitchecken van uw pijplijn.

Als u de instelling in YAML wilt configureren, stelt u de fetchTags eigenschap in.

steps:
- checkout: self
  fetchTags: true

U kunt deze instelling ook configureren met behulp van de optie Labels synchroniseren in de gebruikersinterface voor pijplijninstellingen.

1. Bewerk uw YAML-pijplijn en kies Meer acties, Triggers.

   

2. Kies YAML, Bronnen ophalen.

   

3. Configureer de instelling Synchronisatietags .

   

Notitie

Als u expliciet in uw checkout stap hebt ingesteldfetchTags, heeft die instelling voorrang op de instelling die is geconfigureerd in de gebruikersinterface voor pijplijninstellingen.

Klassiek

U kunt de instelling Labels synchroniseren configureren vanuit de eigenschappen van de taak Bronnen ophalen in uw pijplijn.

Standaardgedrag

• Voor bestaande pijplijnen die zijn gemaakt vóór de release van Azure DevOps sprint 209, uitgebracht in september 2022, blijft de standaardwaarde voor het synchroniseren van tags hetzelfde als het bestaande gedrag voordat de opties voor synchronisatietags zijn toegevoegd. Dit is true.
• Voor nieuwe pijplijnen die zijn gemaakt na release 209 van Azure DevOps sprint, is falsede standaardinstelling voor het synchroniseren van tags.

Notitie

Als u expliciet in uw checkout stap hebt ingesteldfetchTags, heeft die instelling voorrang op de instelling die is geconfigureerd in de gebruikersinterface voor pijplijninstellingen.

Ondiep ophalen

Mogelijk wilt u beperken hoe ver terug in de geschiedenis moet worden gedownload. Dit resulteert effectief in git fetch --depth=n. Als uw opslagplaats groot is, kan deze optie uw build-pijplijn efficiënter maken. Uw opslagplaats kan groot zijn als deze al lange tijd in gebruik is en een grote geschiedenis heeft. Het kan ook groot zijn als u grote bestanden hebt toegevoegd en later hebt verwijderd.

Belangrijk

Nieuwe pijplijnen die zijn gemaakt na de Azure DevOps sprint 209-update van september 2022, hebben Ondiep ophalen standaard ingeschakeld en geconfigureerd met een diepte van 1. Voorheen was de standaardwaarde niet ondiep ophalen. Als u de pijplijn wilt controleren, bekijkt u de instelling Voor ondiep ophalen in de gebruikersinterface voor pijplijninstellingen, zoals beschreven in de volgende sectie.

YAML

U kunt de fetchDepth instelling configureren in de stap Uitchecken van uw pijplijn.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

U kunt ook diepte voor ophalen configureren door de optie Ondiepe diepte in de gebruikersinterface van de pijplijninstellingen in te stellen.

1. Bewerk uw YAML-pijplijn en kies Meer acties, Triggers.

   

2. Kies YAML, Bronnen ophalen.

   

3. Configureer de instelling Voor ondiep ophalen . Schakel Ondiep ophalen uit om ondiep ophalen uit te schakelen of schakel het selectievakje in en voer een diepte in om ondiep ophalen mogelijk te maken.

   

Notitie

Als u expliciet in uw checkout stap hebt ingesteldfetchDepth, heeft die instelling voorrang op de instelling die is geconfigureerd in de gebruikersinterface voor pijplijninstellingen. Instelling fetchDepth: 0 haalt alle geschiedenis op en overschrijft de instelling Ondiep ophalen .

Klassiek

U kunt de instelling Ondiep ophalen configureren op basis van de eigenschappen van de taak Bronnen ophalen in uw pijplijn.

In deze gevallen kunt u met deze optie netwerk- en opslagbronnen besparen. Het kan ook tijd besparen. De reden waarom het niet altijd tijd bespaart, is omdat in sommige situaties de server mogelijk tijd moet besteden aan het berekenen van de doorvoeringen die moeten worden gedownload voor de diepte die u opgeeft.

Notitie

Wanneer de pijplijn wordt gestart, wordt de vertakking om te bouwen omgezet in een doorvoer-id. Vervolgens haalt de agent de vertakking op en controleert de gewenste doorvoering. Er is een klein venster tussen wanneer een vertakking wordt omgezet in een doorvoer-id en wanneer de agent het uitchecken uitvoert. Als de vertakking snel wordt bijgewerkt en u een zeer kleine waarde instelt voor ondiep ophalen, bestaat de doorvoer mogelijk niet wanneer de agent deze probeert te controleren. Als dat gebeurt, verhoogt u de instelling voor ondiepe ophaaldiepte.

Bronnen niet synchroniseren

Mogelijk wilt u het ophalen van nieuwe doorvoeringen overslaan. Deze optie kan handig zijn in gevallen waarin u het volgende wilt doen:

• Git init, configuratie en ophalen met uw eigen aangepaste opties.

• Gebruik een build-pijplijn om alleen automatisering uit te voeren (bijvoorbeeld sommige scripts) die niet afhankelijk zijn van code in versiebeheer.

YAML

U kunt de instelling Synchronisatiebronnen niet configureren in de stap Uitchecken van uw pijplijn door de instelling in te stellencheckout: none.

steps:
- checkout: none  # Don't sync sources

Klassiek

Selecteer de instelling Bronnen niet synchroniseren in de eigenschappen van de taak Bronnen ophalen in uw pijplijn.

Notitie

Wanneer u deze optie gebruikt, slaat de agent ook de uitvoering van Git-opdrachten over die de opslagplaats opschonen.

Schone build

U kunt verschillende vormen van het opschonen van de werkmap van uw zelf-hostende agent uitvoeren voordat een build wordt uitgevoerd.

Over het algemeen moet u de opslagplaats niet opschonen voor snellere prestaties van uw zelf-hostende agents. Als u in dit geval de beste prestaties wilt krijgen, moet u ervoor zorgen dat u ook incrementeel bouwt door de optie Opschonen uit te schakelen van de taak of het hulpprogramma dat u gebruikt om te bouwen.

Als u de opslagplaats moet opschonen (bijvoorbeeld om problemen te voorkomen die worden veroorzaakt door restbestanden uit een eerdere build), vindt u de onderstaande opties.

Notitie

Schoonmaken is niet effectief als u een door Microsoft gehoste agent gebruikt, omdat u elke keer een nieuwe agent krijgt.

YAML

U kunt de clean instelling configureren in de stap Uitchecken van uw pijplijn.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Wanneer clean deze is ingesteld op true de build-pijplijn, worden wijzigingen in $(Build.SourcesDirectory)de build-pijplijn ongedaan maken. Meer specifiek worden de volgende Git-opdrachten uitgevoerd voordat de bron wordt opgehaald.

git clean -ffdx
git reset --hard HEAD

Voor meer opties kunt u de workspace instelling van een taak configureren.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Dit biedt de volgende schone opties.

• uitvoer: Dezelfde bewerking als de schone instelling die wordt beschreven in de vorige uitchecktaak, plus: Verwijdert en maakt opnieuw$(Build.BinariesDirectory). Houd er rekening mee dat de $(Build.ArtifactStagingDirectory) en $(Common.TestResultsDirectory) altijd worden verwijderd en opnieuw worden gemaakt vóór elke build, ongeacht een van deze instellingen.

• resources: verwijdert en maakt deze $(Build.SourcesDirectory)opnieuw. Dit resulteert in het initialiseren van een nieuwe, lokale Git-opslagplaats voor elke build.

• alle: verwijdert en maakt opnieuw $(Agent.BuildDirectory). Dit resulteert in het initialiseren van een nieuwe, lokale Git-opslagplaats voor elke build.

Klassiek

Selecteer de instelling Opschonen in de eigenschappen van de taak Bronnen ophalen in uw pijplijn en selecteer een van de volgende opties.

• Bronnen: De build-pijplijn voert een ongedaan maken van wijzigingen in $(Build.SourcesDirectory). Meer specifiek worden de volgende Git-opdrachten uitgevoerd voordat de bron wordt opgehaald.

  git clean -ffdx
  git reset --hard HEAD
  

• Bronnen en uitvoermap: Dezelfde bewerking als de bovenstaande optie Bronnen , plus: Verwijdert en maakt opnieuw $(Build.BinariesDirectory). Houd er rekening mee dat de $(Build.ArtifactStagingDirectory) en $(Common.TestResultsDirectory) altijd worden verwijderd en opnieuw worden gemaakt vóór elke build, ongeacht een van deze instellingen.

• Bronmap: Verwijdert en maakt deze $(Build.SourcesDirectory)opnieuw. Dit resulteert in het initialiseren van een nieuwe, lokale Git-opslagplaats voor elke build.

• Alle buildmappen: verwijdert en maakt deze $(Agent.BuildDirectory)opnieuw. Dit resulteert in het initialiseren van een nieuwe, lokale Git-opslagplaats voor elke build.

Labelbronnen

U kunt uw broncodebestanden labelen om uw team in staat te stellen eenvoudig te bepalen welke versie van elk bestand is opgenomen in de voltooide build. U kunt ook opgeven of de broncode moet worden gelabeld voor alle builds of alleen voor geslaagde builds.

YAML

U kunt deze instelling momenteel niet configureren in YAML, maar wel in de klassieke editor. Wanneer u een YAML-pijplijn bewerkt, hebt u toegang tot de klassieke editor door triggers te kiezen in het menu van de YAML-editor.

Kies YAML in de klassieke editor, kies de taak Bronnen ophalen en configureer vervolgens de gewenste eigenschappen daar.

Klassiek

U kunt de instelling Tagbronnen configureren vanuit de eigenschappen van de taak Bronnen ophalen in uw pijplijn.

In de tagindeling kunt u door de gebruiker gedefinieerde en vooraf gedefinieerde variabelen gebruiken die een bereik van 'Alle' hebben. Bijvoorbeeld:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

De eerste vier variabelen zijn vooraf gedefinieerd. My.Variable kan door u worden gedefinieerd op het tabblad Variabelen.

De build-pijplijn labelt uw bronnen met een Git-tag.

Sommige buildvariabelen kunnen een waarde opleveren die geen geldig label is. Variabelen zoals $(Build.RequestedFor) en $(Build.DefinitionName) kunnen bijvoorbeeld witruimte bevatten. Als de waarde witruimte bevat, wordt de tag niet gemaakt.

Nadat de bronnen zijn gelabeld door uw build-pijplijn, wordt er automatisch een artefact met de Git-ref refs/tags/{tag} toegevoegd aan de voltooide build. Dit geeft uw team extra traceerbaarheid en een meer gebruiksvriendelijke manier om van de build naar de code te navigeren die is gebouwd. De tag wordt beschouwd als een build-artefact omdat deze wordt geproduceerd door de build. Wanneer de build handmatig of via een bewaarbeleid wordt verwijderd, wordt de tag ook verwijderd.

Vooraf gedefinieerde variabelen

Wanneer u een GitHub-opslagplaats bouwt, zijn de meeste vooraf gedefinieerde variabelen beschikbaar voor uw taken. Omdat Azure Pipelines echter niet de identiteit herkent van een gebruiker die een update maakt in GitHub, worden de volgende variabelen ingesteld op systeemidentiteit in plaats van de identiteit van de gebruiker:

• Build.RequestedFor
• Build.RequestedForId
• Build.RequestedForEmail

Statusupdates

Er zijn twee typen statussen die Azure Pipelines terugstuurt naar GitHub: basisstatussen en GitHub Check Runs. GitHub Checks-functionaliteit is alleen beschikbaar voor GitHub-apps.

Pijplijnstatussen worden weergegeven op verschillende plaatsen in de GitHub-gebruikersinterface.

• Voor PULL's worden ze weergegeven op het tabblad Pr-gesprekken.
• Voor afzonderlijke doorvoeringen worden ze weergegeven wanneer u de muisaanwijzer boven de statusmarkering plaatst na de doorvoertijd op het tabblad Doorvoeringen van de opslagplaats.

PAT- of OAuth GitHub-verbindingen

Voor pijplijnen die PAT- of OAuth GitHub-verbindingen gebruiken, worden statussen teruggezet naar de doorvoer/pull-aanvraag die de uitvoering heeft geactiveerd. De GitHub-status-API wordt gebruikt om dergelijke updates te posten. Deze statussen bevatten beperkte informatie: pijplijnstatus (mislukt, geslaagd), URL om terug te koppelen aan de build-pijplijn en een korte beschrijving van de status.

Statussen voor PAT- of OAuth GitHub-verbindingen worden alleen verzonden op uitvoeringsniveau. Met andere woorden, u kunt één status hebben bijgewerkt voor een volledige uitvoering. Als u meerdere taken in een uitvoering hebt, kunt u voor elke taak geen afzonderlijke status posten. Meerdere pijplijnen kunnen echter afzonderlijke statussen posten op dezelfde doorvoering.

GitHub-controles

Voor pijplijnen die zijn ingesteld met behulp van de GitHub-app Azure Pipelines, wordt de status teruggezet in de vorm van GitHub-controles. GitHub-controles maken het verzenden van gedetailleerde informatie over de pijplijnstatus en -test, codedekking en fouten mogelijk. De GitHub Checks-API vindt u hier.

Voor elke pijplijn die de GitHub-app gebruikt, worden controles teruggezet voor de algehele uitvoering en elke taak in die uitvoering.

GitHub biedt drie opties wanneer een of meer controleuitvoeringen mislukken voor een pull-aanvraag/doorvoer. U kunt ervoor kiezen om de afzonderlijke controle opnieuw uit te voeren, alle mislukte controles op die pull-aanvraag/doorvoer opnieuw uit te voeren of alle controles opnieuw uit te voeren, ongeacht of ze in eerste instantie zijn geslaagd.

Als u op de koppeling Opnieuw uitvoeren klikt naast de naam van de controleuitvoering, wordt de uitvoering die is gegenereerd opnieuw uitgevoerd in Azure Pipelines. De resulterende uitvoering heeft hetzelfde uitvoeringsnummer en gebruikt dezelfde versie van de broncode, configuratie en YAML-bestand als de eerste build. Alleen taken die zijn mislukt tijdens de eerste uitvoering en eventuele afhankelijke downstreamtaken worden opnieuw uitgevoerd. Als u op de koppeling Alle mislukte controles opnieuw uitvoeren klikt, heeft dit hetzelfde effect. Dit is hetzelfde gedrag als klikken op Opnieuw uitvoeren in de gebruikersinterface van Azure Pipelines. Als u op Alle controles opnieuw uitvoeren klikt, resulteert dit in een nieuwe uitvoering, met een nieuw uitvoeringsnummer en worden wijzigingen in het configuratie- of YAML-bestand opgehaald.

Beperkingen

• Voor de beste prestaties raden we maximaal 50 pijplijnen in één opslagplaats aan. Voor acceptabele prestaties raden we maximaal 100 pijplijnen aan in één opslagplaats. De tijd die nodig is om een push naar een opslagplaats te verwerken, neemt toe met het aantal pijplijnen in die opslagplaats. Wanneer er naar een opslagplaats wordt gepusht, moeten azure Pipelines alle YAML-pijplijnen in die opslagplaats laden om erachter te komen of een van deze pijplijnen moet worden uitgevoerd en elke pijplijn wordt geladen, wordt een prestatiestraf opgelegd. Naast prestatieproblemen kan het hebben van te veel pijplijnen in één opslagplaats leiden tot beperking aan de zijde van GitHub, omdat Azure Pipelines in korte tijd te veel aanvragen kan indienen.
• Het gebruik van uitbreidingen en het opnemen van sjablonen in een pijplijn heeft invloed op de snelheid waarmee Azure Pipelines GitHub API-aanvragen doet en kan leiden tot beperking aan de zijde van GitHub. Voordat u een pijplijn uitvoert, moet Azure Pipelines de volledige YAML-code genereren, zodat alle sjabloonbestanden moeten worden opgehaald.
• 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 GitHub-integratie vallen in de volgende categorieën:

• Verbinding maken iontypen: Ik weet niet welk verbindingstype ik gebruik om mijn pijplijn te verbinden met GitHub.
• Mislukte triggers: Mijn pijplijn wordt niet geactiveerd wanneer ik een update naar de opslagplaats push.
• Uitchecken mislukt: Mijn pijplijn wordt geactiveerd, maar mislukt in de stap voor uitchecken.
• Verkeerde versie: Mijn pijplijn wordt uitgevoerd, maar er wordt een onverwachte versie van de bron/YAML gebruikt.
• Ontbrekende statusupdates: Mijn GitHub-PULL's worden geblokkeerd omdat Azure Pipelines geen statusupdate heeft gerapporteerd.

Verbindingstypen

Hoe weet ik het type GitHub-verbinding dat ik voor mijn pijplijn gebruik om problemen met triggers op te lossen?

Het oplossen van problemen met triggers is sterk afhankelijk van het type GitHub-verbinding dat u in uw pijplijn gebruikt. Er zijn twee manieren om het type verbinding te bepalen: van GitHub en Van Azure Pipelines.

• Vanuit GitHub: Als een opslagplaats is ingesteld voor het gebruik van de GitHub-app, worden de statussen op PULL's en doorvoeringen Controleuitvoeringen. Als voor de opslagplaats Azure Pipelines zijn ingesteld met OAuth- of PAT-verbindingen, zijn de statussen de 'oude' stijl van statussen. Een snelle manier om te bepalen of de statussen Controleuitvoeringen of eenvoudige statussen zijn, is door te kijken naar het tabblad Gesprek in een GitHub-pull-aanvraag.

  • Als de koppeling Details omleidt naar het tabblad Controles, is het een controleuitvoering en gebruikt de opslagplaats de app.
  • Als de koppeling Details omleidt naar de Azure DevOps-pijplijn, is de status een 'oude stijl' status en gebruikt de opslagplaats de app niet.

• Vanuit Azure Pipelines: U kunt ook het type verbinding bepalen door de pijplijn in de gebruikersinterface van Azure Pipelines te inspecteren. Open de editor voor de pijplijn. Selecteer Triggers om de klassieke editor voor de pijplijn te openen. Selecteer vervolgens het tabblad YAML en vervolgens de stap Bronnen ophalen. U ziet een banner geautoriseerd met behulp van een verbinding: hiermee wordt aangegeven welke serviceverbinding is gebruikt om de pijplijn te integreren met GitHub. De naam van de serviceverbinding is een hyperlink. Selecteer deze om naar de eigenschappen van de serviceverbinding te navigeren. De eigenschappen van de serviceverbinding geven het type verbinding aan dat wordt gebruikt:

  • De Azure Pipelines-app geeft de verbinding van de GitHub-app aan
  • oauth geeft de OAuth-verbinding aan
  • personalaccesstoken geeft PAT-verificatie aan

Hoe kan ik mijn pijplijn overschakelen naar het gebruik van de GitHub-app in plaats van OAuth?

Het gebruik van een GitHub-app in plaats van een OAuth- of PAT-verbinding is de aanbevolen integratie tussen GitHub en Azure Pipelines. Ga als volgt te werk om over te schakelen naar de GitHub-app:

1. Navigeer hier en installeer de app in de GitHub-organisatie van uw opslagplaats.
2. Tijdens de installatie wordt u omgeleid naar Azure DevOps om een Azure DevOps-organisatie en -project te kiezen. Kies de organisatie en het project met de klassieke build-pijplijn waarvoor u de app wilt gebruiken. Deze keuze koppelt de installatie van de GitHub-app aan uw Azure DevOps-organisatie. Als u onjuist kiest, kunt u deze pagina bezoeken om de GitHub-app te verwijderen uit uw GitHub-organisatie en opnieuw te beginnen.
3. Op de volgende pagina die wordt weergegeven, hoeft u niet verder te gaan met het maken van een nieuwe pijplijn.
4. Bewerk uw pijplijn door naar de pagina Pijplijnen te gaan (bijvoorbeeld https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build)door uw pijplijn te selecteren en op Bewerken te klikken.
5. Als dit een YAML-pijplijn is, selecteert u het menu Triggers om de klassieke editor te openen.
6. Selecteer de stap Bronnen ophalen in de pijplijn.
7. Selecteer op de groene balk met de tekst 'Geautoriseerd met behulp van verbinding' de optie 'Wijzigen' en selecteer de Verbinding met de GitHub-app met dezelfde naam als de GitHub-organisatie waarin u de app hebt geïnstalleerd.
8. Selecteer 'Opslaan en wachtrij' op de werkbalk en vervolgens 'Opslaan en wachtrij'. Selecteer de koppeling naar de pijplijnuitvoering die in de wachtrij is geplaatst om er zeker van te zijn dat deze slaagt.
9. Maak (of sluit en open opnieuw) een pull-aanvraag in uw GitHub-opslagplaats om te controleren of een build in de wachtrij staat in de sectie Controles.

Waarom wordt er geen GitHub-opslagplaats weergegeven die voor mij wordt weergegeven om te kiezen in Azure Pipelines?

Afhankelijk van het verificatietype en het eigendom van de opslagplaats zijn specifieke machtigingen vereist.

• Als u de GitHub-app gebruikt, raadpleegt u GitHub App-verificatie.
• Als u OAuth gebruikt, raadpleegt u OAuth-verificatie.
• Als u PAT's gebruikt, raadpleegt u Verificatie van persoonlijk toegangstoken (PAT).

Wanneer ik een opslagplaats selecteer tijdens het maken van een pijplijn, krijg ik de foutmelding 'De opslagplaats {opslagplaatsnaam} wordt gebruikt met de GitHub-app van Azure Pipelines in een andere Azure DevOps-organisatie.'

Dit betekent dat uw opslagplaats al is gekoppeld aan een pijplijn in een andere organisatie. CI- en PULL-gebeurtenissen uit deze opslagplaats werken niet omdat ze worden geleverd aan de andere organisatie. Hier volgen de stappen die u moet uitvoeren om de toewijzing aan de andere organisatie te verwijderen voordat u doorgaat met het maken van een pijplijn.

1. Open een pull-aanvraag in uw GitHub-opslagplaats en maak de opmerking /azp where. Hiermee wordt de Azure DevOps-organisatie gerapporteerd waaraan de opslagplaats is toegewezen.

2. Als u de toewijzing wilt wijzigen, verwijdert u de app van de GitHub-organisatie en installeert u deze opnieuw. Wanneer u deze opnieuw installeert, moet u ervoor zorgen dat u de juiste organisatie selecteert wanneer u wordt omgeleid naar Azure DevOps.

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.

  

• Gebruikt u de Verbinding van de GitHub-app om de pijplijn te verbinden met GitHub? Zie Verbinding maken iontypen om het type verbinding te bepalen dat u hebt. Als u een Verbinding met een GitHub-app gebruikt, voert u de volgende stappen uit:

  • Is de toewijzing correct ingesteld tussen GitHub en Azure DevOps? Open een pull-aanvraag in uw GitHub-opslagplaats en maak de opmerking /azp where. Hiermee wordt de Azure DevOps-organisatie gerapporteerd waaraan de opslagplaats is toegewezen.

    • Als er geen organisaties zijn ingesteld om deze opslagplaats te bouwen met behulp van de app, gaat u naar https://github.com/<org_name>/<repo_name>/settings/installations en voltooit u de configuratie van de app.

    • Als een andere Azure DevOps-organisatie wordt gerapporteerd, heeft iemand al een pijplijn voor deze opslagplaats in een andere organisatie gemaakt. We hebben momenteel de beperking dat we alleen een GitHub-opslagplaats kunnen toewijzen aan één DevOps-organisatie. Alleen de pijplijnen in de eerste Azure DevOps-organisatie kunnen automatisch worden geactiveerd. Als u de toewijzing wilt wijzigen, verwijdert u de app van de GitHub-organisatie en installeert u deze opnieuw. Wanneer u deze opnieuw installeert, moet u ervoor zorgen dat u de juiste organisatie selecteert wanneer u wordt omgeleid naar Azure DevOps.

• Gebruikt u OAuth of PAT om de pijplijn te verbinden met GitHub? Zie Verbinding maken iontypen om het type verbinding te bepalen dat u hebt. Als u een GitHub-verbinding gebruikt, voert u de volgende stappen uit:

  1. OAuth- en PAT-verbindingen zijn afhankelijk van webhooks om updates te communiceren met Azure Pipelines. Navigeer in GitHub naar de instellingen voor uw opslagplaats en ga vervolgens naar Webhooks. Controleer of de webhooks bestaan. Meestal ziet u drie webhooks: pushen, pull_request en issue_comment. Als u dat niet doet, moet u de serviceverbinding opnieuw maken en de pijplijn bijwerken om de nieuwe serviceverbinding te gebruiken.

  2. Selecteer elk van de webhooks in GitHub en controleer of de nettolading die overeenkomt met de doorvoer van de gebruiker bestaat en is verzonden naar Azure DevOps. Mogelijk ziet u hier een fout als de gebeurtenis niet kan worden gecommuniceerd met Azure DevOps.

• Het verkeer van Azure DevOps kan worden beperkt door GitHub. Wanneer Azure Pipelines een melding van GitHub ontvangt, probeert deze contact op te nemen met GitHub en meer informatie over de opslagplaats en het YAML-bestand op te halen. Als u een opslagplaats met een groot aantal updates en pull-aanvragen hebt, kan deze aanroep mislukken vanwege dergelijke beperking. In dit geval kunt u zien of u de frequentie van builds kunt verminderen met behulp van batchverwerking of strengere pad-/vertakkingsfilters.

• 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 en volg deze aanvullende stappen:

• 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 meestal een vertraging 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. Hier volgen enkele redenen waarom een vertraging kan optreden:

  • Er is een servicestoring op onze statuspagina. 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.
  • Uw opslagplaats bevat te veel YAML-pijplijnen. Voor de beste prestaties raden we maximaal 50 pijplijnen in één opslagplaats aan. Voor acceptabele prestaties raden we maximaal 100 pijplijnen aan in één opslagplaats. Hoe meer pijplijnen er zijn, hoe langzamer de verwerking van een push naar die opslagplaats. Wanneer er naar een opslagplaats wordt gepusht, moeten azure Pipelines alle YAML-pijplijnen in die opslagplaats laden om erachter te komen of een van deze pijplijnen moet worden uitgevoerd en elke nieuwe pijplijn een prestatiestraf krijgt.

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.

Uitchecken mislukt

Ik zie de volgende fout in het logboekbestand tijdens het uitchecken. Hoe los ik dit op?

remote: Repository not found.
fatal: repository <repo> not found

Dit kan worden veroorzaakt door een storing in GitHub. Probeer toegang te krijgen tot de opslagplaats in GitHub en zorg ervoor dat u dat kunt.

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.

Ontbrekende statusupdates

Mijn pull-aanvraag in GitHub wordt geblokkeerd omdat Azure Pipelines de status niet heeft bijgewerkt.

Dit kan een tijdelijke fout zijn waardoor Azure DevOps niet kan communiceren met GitHub. Voer het inchecken van GitHub opnieuw uit als u de GitHub-app gebruikt. Of maak een triviale update voor de pull-aanvraag om te zien of het probleem kan worden opgelost.

Verwante artikelen:

• Geplande triggers
• Voltooiingstriggers voor pijplijn