Dela via

Skapa GitHub-lagringsplatser

  • Artikel

Azure DevOps Services

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

Om du är nybörjare på pipelines-integrering med GitHub följer du stegen i Skapa din första pipeline. Gå tillbaka till den här artikeln om du vill veta mer om hur du konfigurerar och anpassar integreringen mellan GitHub och Azure Pipelines.

Organisationer och användare

GitHub och Azure Pipelines är två oberoende tjänster som integreras väl tillsammans. Var och en av dem har sin egen organisation och användarhantering. Det här avsnittet ger en rekommendation om hur du replikerar organisationen och användarna från GitHub till Azure Pipelines.

Organisationer

GitHubs struktur består av organisationer och användarkonton som innehåller lagringsplatser. Se GitHubs dokumentation.

GitHub-organisationsstruktur

Azure DevOps struktur består av organisationer som innehåller projekt. Se Planera din organisationsstruktur.

Organisationsstruktur för Azure DevOps

Azure DevOps kan återspegla din GitHub-struktur med:

  • En DevOps-organisation för din GitHub-organisation eller ditt användarkonto
  • DevOps Projects för dina GitHub-lagringsplatser

GitHub-struktur mappad till Azure DevOps

Så här konfigurerar du en identisk struktur i Azure DevOps:

  1. Skapa en DevOps-organisation med namnet efter din GitHub-organisation eller ditt användarkonto. Den har en URL som https://dev.azure.com/your-organization.
  2. I DevOps-organisationen skapar du projekt med namnet efter dina lagringsplatser. De har URL:er som https://dev.azure.com/your-organization/your-repository.
  3. I DevOps-projektet skapar du pipelines med namnet efter den GitHub-organisation och lagringsplats som de skapar, till exempel your-organization.your-repository. Sedan är det tydligt vilka lagringsplatser de är till för.

Efter det här mönstret har dina GitHub-lagringsplatser och Azure DevOps Projects matchande URL-sökvägar. Till exempel:

Tjänst webbadress
GitHub https://github.com/python/cpython
Azure DevOps https://dev.azure.com/python/cpython

Användare

Dina GitHub-användare får inte automatiskt åtkomst till Azure Pipelines. Azure Pipelines känner inte till GitHub-identiteter. Därför finns det inget sätt att konfigurera Azure Pipelines för att automatiskt meddela användare om ett byggfel eller ett PR-valideringsfel med hjälp av deras GitHub-identitet och e-postadress. Du måste uttryckligen skapa nya användare i Azure Pipelines för att replikera GitHub-användare. När du har skapat nya användare kan du konfigurera deras behörigheter i Azure DevOps så att de återspeglar deras behörigheter i GitHub. Du kan också konfigurera meddelanden i DevOps med hjälp av deras DevOps-identitet.

GitHub-organisationsroller

GitHub-organisationsmedlemsroller finns på https://github.com/orgs/your-organization/people (ersätt your-organization).

DevOps-organisationsmedlemsbehörigheter finns på https://dev.azure.com/your-organization/_settings/security (ersätt your-organization).

Roller i en GitHub-organisation och motsvarande roller i en Azure DevOps-organisation visas nedan.

GitHub-organisationsroll Motsvarande DevOps-organisation
Ägare Medlem i Project Collection Administrators
Faktureringshanterare Medlem i Project Collection Administrators
Medlem Medlem i Project Collection Valid Users. Som standard saknar medlemsgruppen behörighet att skapa nya projekt. Om du vill ändra behörigheten anger du gruppens Create new projects behörighet till Alloweller skapar en ny grupp med behörigheter som du behöver.

GitHub-användarkontoroller

Ett GitHub-användarkonto har en roll som är ägarskap för kontot.

DevOps-organisationsmedlemsbehörigheter finns på https://dev.azure.com/your-organization/_settings/security (ersätt your-organization).

GitHub-användarkontorollen mappar till DevOps-organisationsbehörigheter enligt följande.

GitHub-användarkontoroll Motsvarande DevOps-organisation
Ägare Medlem i Project Collection Administrators

Behörigheter för GitHub-lagringsplats

GitHub-lagringsplatsens behörigheter finns på https://github.com/your-organization/your-repository/settings/collaboration (ersätt your-organization och your-repository).

DevOps-projektbehörigheter finns på https://dev.azure.com/your-organization/your-project/_settings/security (ersätt your-organization och your-project).

Motsvarande behörigheter mellan GitHub-lagringsplatser och Azure DevOps Projects är följande.

GitHub-lagringsplatsbehörighet Motsvarande DevOps-projekt
Administratör Medlem i Project Administrators
Skriva Medlem i Contributors
Lästa Medlem i Readers

Om din GitHub-lagringsplats ger behörighet till team kan du skapa matchande team i avsnittet i Teams dina Azure DevOps-projektinställningar. Lägg sedan till teamen i säkerhetsgrupperna ovan, precis som användare.

Pipelinespecifika behörigheter

Följ dessa steg om du vill bevilja behörigheter till användare eller team för specifika pipelines i ett DevOps-projekt:

  1. Besök projektets pipelines-sida (till exempel https://dev.azure.com/your-organization/your-project/_build).
  2. Välj den pipeline som du vill ange specifika behörigheter för.
  3. På snabbmenyn ...väljer du Säkerhet.
  4. Välj Lägg till... för att lägga till en specifik användare, ett team eller en grupp och anpassa deras behörigheter för pipelinen.

Åtkomst till GitHub-lagringsplatser

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

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

Azure Pipelines måste beviljas åtkomst till dina lagringsplatser för att utlösa deras versioner och hämta koden under byggen.

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

Authentication type Pipelines körs med Fungerar med GitHub-kontroller
1. GitHub App Azure Pipelines-identiteten Ja
2. OAuth Din personliga GitHub-identitet Nej
3. Personlig åtkomsttoken (PAT) Din personliga GitHub-identitet Nej

GitHub-appautentisering

GitHub-appen för Azure Pipelines är den rekommenderade autentiseringstypen för pipelines för kontinuerlig integrering. När du har installerat GitHub-appen i ditt GitHub-konto eller din organisation körs pipelinen utan att använda din personliga GitHub-identitet. Uppdateringar av byggen och GitHub-status utförs med hjälp av Azure Pipelines-identiteten. Appen fungerar med GitHub Checks för att visa resultat för bygg-, test- och kodtäckning i GitHub.

Om du vill använda GitHub-appen installerar du den i din GitHub-organisation eller ditt användarkonto för vissa eller alla lagringsplatser. GitHub-appen kan installeras och avinstalleras från appens startsida.

Efter installationen blir GitHub-appen Azure Pipelines standardmetod för autentisering till GitHub (i stället för OAuth) när pipelines skapas för lagringsplatserna.

Om du installerar GitHub-appen för alla lagringsplatser i en GitHub-organisation behöver du inte bekymra dig om att Azure Pipelines skickar massmeddelanden eller konfigurerar pipelines automatiskt åt dig. Som ett alternativ till att installera appen för alla lagringsplatser kan databasadministratörer installera den en i taget för enskilda lagringsplatser. Detta kräver mer arbete för administratörer, men har ingen fördel eller nackdel.

Behörigheter som behövs i GitHub

Installationen av GitHub-appen i Azure Pipelines kräver att du är github-organisationsägare eller lagringsplatsadministratör. För att kunna skapa en pipeline för en GitHub-lagringsplats med utlösare för kontinuerlig integrering och pull-begäran måste du dessutom ha de nödvändiga GitHub-behörigheterna konfigurerade. Annars visas inte lagringsplatsen i lagringsplatsens lista när du skapar en pipeline. Beroende på autentiseringstyp och ägarskap för lagringsplatsen kontrollerar du att rätt åtkomst har konfigurerats.

  • Om lagringsplatsen finns i ditt personliga GitHub-konto installerar du Azure Pipelines GitHub-appen på ditt personliga GitHub-konto, så kan du lista den här lagringsplatsen när du skapar pipelinen i Azure Pipelines.

  • Om lagringsplatsen finns i någon annans personliga GitHub-konto måste den andra personen installera Azure Pipelines GitHub-appen på sitt personliga GitHub-konto. Du måste läggas till som medarbetare i lagringsplatsens inställningar under "Medarbetare". Acceptera inbjudan att vara medarbetare med hjälp av länken som skickas via e-post till dig. När du har gjort det kan du skapa en pipeline för lagringsplatsen.

  • Om lagringsplatsen finns i en GitHub-organisation som du äger installerar du GitHub-appen Azure Pipelines i GitHub-organisationen. Du måste också läggas till som medarbetare, eller så måste ditt team läggas till i lagringsplatsens inställningar under "Medarbetare och team".

  • Om lagringsplatsen finns i en GitHub-organisation som någon annan äger måste en GitHub-organisationsägare eller lagringsplatsadministratör installera Azure Pipelines GitHub-appen i organisationen. Du måste läggas till som medarbetare, eller så måste ditt team läggas till i lagringsplatsens inställningar under "Medarbetare och team". Acceptera inbjudan att vara medarbetare med hjälp av länken som skickas via e-post till dig.

GitHub App-behörigheter

GitHub-appen begär följande behörigheter under installationen:

Behörighet Så använder Azure Pipelines behörigheten
Skriva åtkomst till kod Azure Pipelines förenklar bara skapandet av en pipeline genom att checka in en YAML-fil till en vald gren av GitHub-lagringsplatsen.
Läsåtkomst till metadata Azure Pipelines hämtar GitHub-metadata för att visa lagringsplatsen, grenarna och problem som är associerade med en version i kompileringens sammanfattning.
Läs- och skrivåtkomst till kontroller Azure Pipelines läser och skriver sina egna bygg-, test- och kodtäckningsresultat som ska visas i GitHub.
Läs- och skrivåtkomst till pull-begäranden Azure Pipelines förenklar bara skapandet av en pipeline genom att skapa en pull-begäran för en YAML-fil som har checkats in på en vald gren av GitHub-lagringsplatsen. Pipelines hämtar begärandemetadata som ska visas i versionssammanfattningar som är associerade med pull-begäranden.

Felsöka installation av GitHub-appar

GitHub kan visa ett fel som:

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

Det innebär att GitHub-appen troligen redan är installerad för din organisation. När du skapar en pipeline för en lagringsplats i organisationen används GitHub-appen automatiskt för att ansluta till GitHub.

Skapa pipelines i flera Azure DevOps-organisationer och -projekt

När GitHub-appen har installerats kan pipelines skapas för organisationens lagringsplatser i olika Azure DevOps-organisationer och -projekt. Men om du skapar pipelines för en enda lagringsplats i flera Azure DevOps-organisationer kan endast den första organisationens pipelines utlösas automatiskt av GitHub-incheckningar eller pull-begäranden. Manuella eller schemalagda versioner är fortfarande möjliga i sekundära Azure DevOps-organisationer.

OAuth-autentisering

OAuth är den enklaste autentiseringstypen att komma igång med för lagringsplatser i ditt personliga GitHub-konto. GitHub-statusuppdateringar utförs för din personliga GitHub-identitet. För att pipelines ska fortsätta att fungera måste lagringsplatsens åtkomst förbli aktiv. Vissa GitHub-funktioner, till exempel Kontroller, är inte tillgängliga med OAuth och kräver GitHub-appen.

Om du vill använda OAuth väljer du Välj en annan anslutning under listan över lagringsplatser när du skapar en pipeline. Välj sedan Auktorisera för att logga in på GitHub och auktorisera med OAuth. En OAuth-anslutning sparas i ditt Azure DevOps-projekt för senare användning och används i pipelinen som skapas.

Behörigheter som behövs i GitHub

Om du vill skapa en pipeline för en GitHub-lagringsplats med utlösare för kontinuerlig integrering och pull-begäran måste du ha de nödvändiga GitHub-behörigheterna konfigurerade. Annars visas inte lagringsplatsen i lagringsplatsens lista när du skapar en pipeline. Beroende på autentiseringstyp och ägarskap för lagringsplatsen kontrollerar du att rätt åtkomst har konfigurerats.

  • Om lagringsplatsen finns i ditt personliga GitHub-konto, minst en gång, autentisera till GitHub med OAuth med dina personliga autentiseringsuppgifter för GitHub-kontot. Detta kan göras i Azure DevOps-projektinställningar under Pipelines > Service-anslutningar > Ny tjänstanslutning > GitHub > Authorize. Ge Azure Pipelines åtkomst till dina lagringsplatser under "Behörigheter" här.

  • Om lagringsplatsen finns i någon annans personliga GitHub-konto, minst en gång, måste den andra personen autentisera till GitHub med OAuth med sina personliga autentiseringsuppgifter för GitHub-kontot. Detta kan göras i Azure DevOps-projektinställningar under Pipelines > Service-anslutningar > Ny tjänstanslutning > GitHub > Authorize. Den andra personen måste ge Azure Pipelines åtkomst till sina lagringsplatser under "Behörigheter" här. Du måste läggas till som medarbetare i lagringsplatsens inställningar under "Medarbetare". Acceptera inbjudan att vara medarbetare med hjälp av länken som skickas via e-post till dig.

  • Om lagringsplatsen finns i en GitHub-organisation som du äger, minst en gång, autentisera till GitHub med OAuth med dina personliga autentiseringsuppgifter för GitHub-kontot. Detta kan göras i Azure DevOps-projektinställningar under Pipelines > Service-anslutningar > Ny tjänstanslutning > GitHub > Authorize. Ge Azure Pipelines åtkomst till din organisation under "Organisationsåtkomst" här. Du måste läggas till som medarbetare, eller så måste ditt team läggas till i lagringsplatsens inställningar under "Medarbetare och team".

  • Om lagringsplatsen finns i en GitHub-organisation som någon annan äger, minst en gång, måste en GitHub-organisationsägare autentisera till GitHub med OAuth med sina personliga autentiseringsuppgifter för GitHub-kontot. Detta kan göras i Azure DevOps-projektinställningar under Pipelines > Service-anslutningar > Ny tjänstanslutning > GitHub > Authorize. Organisationens ägare måste ge Azure Pipelines åtkomst till organisationen under "Organisationsåtkomst" här. Du måste läggas till som medarbetare, eller så måste ditt team läggas till i lagringsplatsens inställningar under "Medarbetare och team". Acceptera inbjudan att vara medarbetare med hjälp av länken som skickas via e-post till dig.

Återkalla OAuth-åtkomst

När du har auktoriserat Azure Pipelines att använda OAuth kan du senare återkalla det och förhindra ytterligare användning genom att gå till OAuth-appar i dina GitHub-inställningar. Du kan också ta bort den från listan över GitHub-tjänstanslutningar i dina Azure DevOps-projektinställningar.

Autentisering med personlig åtkomsttoken (PAT)

PAT:er är i själva verket samma som OAuth, men gör att du kan styra vilka behörigheter som beviljas till Azure Pipelines. Uppdateringar av byggen och GitHub-status utförs för din personliga GitHub-identitet. För att byggen ska fortsätta att fungera måste lagringsplatsens åtkomst förbli aktiv.

Om du vill skapa en PAT går du till Personliga åtkomsttoken i dina GitHub-inställningar. De behörigheter som krävs är repo, admin:repo_hook, read:useroch user:email. Det här är samma behörigheter som krävs när du använder OAuth ovan. Kopiera den genererade PAT:n till Urklipp och klistra in den i en ny GitHub-tjänstanslutning i dina Azure DevOps-projektinställningar. För framtida återkallande, namnge tjänstanslutningen efter ditt GitHub-användarnamn. Den kommer att vara tillgänglig i ditt Azure DevOps-projekt för senare användning när du skapar pipelines.

Behörigheter som behövs i GitHub

Om du vill skapa en pipeline för en GitHub-lagringsplats med utlösare för kontinuerlig integrering och pull-begäran måste du ha de nödvändiga GitHub-behörigheterna konfigurerade. Annars visas inte lagringsplatsen i lagringsplatsens lista när du skapar en pipeline. Beroende på autentiseringstyp och ägarskap för lagringsplatsen kontrollerar du att följande åtkomst är konfigurerad.

  • Om lagringsplatsen finns i ditt personliga GitHub-konto måste PAT ha de åtkomstomfattningar som krävs under Personliga åtkomsttoken: repo, admin:repo_hook, read:useroch user:email.

  • Om lagringsplatsen finns i någon annans personliga GitHub-konto måste PAT ha de åtkomstomfattningar som krävs under Personliga åtkomsttoken: repo, admin:repo_hook, read:useroch user:email. Du måste läggas till som medarbetare i lagringsplatsens inställningar under "Medarbetare". Acceptera inbjudan att vara medarbetare med hjälp av länken som skickas via e-post till dig.

  • Om lagringsplatsen finns i en GitHub-organisation som du äger måste PAT ha de åtkomstomfattningar som krävs under Personliga åtkomsttoken: repo, admin:repo_hook, read:useroch user:email. Du måste läggas till som medarbetare, eller så måste ditt team läggas till i lagringsplatsens inställningar under "Medarbetare och team".

  • Om lagringsplatsen finns i en GitHub-organisation som någon annan äger måste PAT ha de åtkomstomfattningar som krävs under Personliga åtkomsttoken: repo, admin:repo_hook, read:useroch user:email. Du måste läggas till som medarbetare, eller så måste ditt team läggas till i lagringsplatsens inställningar under "Medarbetare och team". Acceptera inbjudan att vara medarbetare med hjälp av länken som skickas via e-post till dig.

Återkalla PAT-åtkomst

När du har auktoriserat Azure Pipelines att använda en PAT kan du senare ta bort den och förhindra ytterligare användning genom att gå till Personliga åtkomsttoken i dina GitHub-inställningar. Du kan också ta bort den från listan över GitHub-tjänstanslutningar i dina Azure DevOps-projektinställningar.

CI-utlösare

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

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

Grenar

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

trigger:
- main
- releases/*

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

Kommentar

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

Kommentar

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

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

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

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

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

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

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

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

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

Viktigt!

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

Batchbearbetning av CI-körningar

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

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

Kommentar

batch stöds inte i lagringsplatsens resursutlösare.

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

Kommentar

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

Sekvenser

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

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

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

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

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

Taggar

Förutom att ange taggar i branches listorna som beskrivs i föregående avsnitt kan du ange taggar som ska inkluderas eller exkluderas direkt:

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

Om du inte anger några taggutlösare utlöser taggar som standard inte pipelines.

Viktigt!

Om du anger taggar i kombination med grenfilter utlöses utlösaren om antingen grenfiltret är uppfyllt eller om taggfiltret är uppfyllt. Om en push-tagg till exempel uppfyller grenfiltret utlöses pipelinen även om taggen undantas av taggfiltret, eftersom push-överföringen uppfyllde grenfiltret.

Avregistrera dig från CI

Inaktivera CI-utlösaren

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

# A pipeline with no CI trigger
trigger: none

Viktigt!

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

Hoppar över CI för enskilda incheckningar

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

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

Använda utlösartypen i villkor

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

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

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

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

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

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

Jokertecken

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

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

PR-utlösare

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

Grenar

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

pr:
- main
- releases/*

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

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

Kommentar

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

Kommentar

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

GitHub skapar en ny referens när en pull-begäran skapas. Referensen pekar på en sammanslagningsincheckning, vilket är den sammanfogade koden mellan käll- och målgrenarna för pull-begäran. PR-valideringspipelinen skapar den incheckning som referensen pekar på. Det innebär att YAML-filen som används för att köra pipelinen också är en sammanslagning mellan källan och målgrenen. Därför kan de ändringar du gör i YAML-filen i källgrenen för pull-begäran åsidosätta det beteende som definieras av YAML-filen i målgrenen.

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

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

Viktigt!

När du anger en pr utlösare med en delmängd grenar utlöses en pipeline endast när uppdateringar skickas till dessa grenar.

För mer komplexa utlösare som behöver exkludera vissa grenar måste du använda den fullständiga syntaxen enligt följande exempel. I det här exemplet verifieras pull-begäranden som mål main eller releases/* och grenen releases/old* undantas.

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

Sekvenser

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

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

Tips:

  • Azure Pipelines publicerar en neutral status tillbaka till GitHub när den bestämmer sig för att inte köra en valideringsversion på grund av en regel för sökvägsundantag. Detta ger en tydlig riktning till GitHub som anger att Azure Pipelines har slutfört bearbetningen. Mer information finns i Publicera neutral status till GitHub när en version hoppas över.
  • Jokertecken stöds nu med sökvägsfilter.
  • Sökvägar anges alltid i förhållande till lagringsplatsens rot.
  • Om du inte anger sökvägsfilter inkluderas lagringsplatsens rotmapp implicit som standard.
  • Om du exkluderar en sökväg kan du inte också inkludera den om du inte kvalificerar den till en djupare mapp. Om du till exempel exkluderar /tools kan du inkludera /tools/trigger-runs-on-these
  • Ordningen på sökvägsfilter spelar ingen roll.
  • Sökvägar i Git är skiftlägeskänsliga. Se till att använda samma skiftläge som de riktiga mapparna.
  • Du kan inte använda variabler i sökvägar, eftersom variabler utvärderas vid körning (när utlösaren har utlösts).
  • Azure Pipelines publicerar en neutral status tillbaka till GitHub när den bestämmer sig för att inte köra en valideringsversion på grund av en regel för sökvägsundantag.

Flera PR-uppdateringar

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

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

Utkast till PR-validering

Som standard utlöses pull-begäranden på utkast pull-begäranden och pull-begäranden som är redo för granskning. Om du vill inaktivera utlösare för pull-begäranden för pull-begäranden anger du egenskapen drafts till 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

Avregistrera dig från PR-validering

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

# no PR triggers
pr: none

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

Kommentar

Om utlösaren pr inte utlöses följer du felsökningsstegen i vanliga frågor och svar.

Om du har en öppen PR och skickar ändringar till dess källgren kan flera pipelines köras:

  • Pipelines som har en PR-utlösare på PR:s målgren körs vid sammanslagningsincheckningen (den sammanfogade koden mellan käll- och målgrenarna i pull-begäran), oavsett om det finns push-incheckningar vars meddelanden eller beskrivningar innehåller [skip ci] (eller någon av dess varianter).
  • Pipelines som utlöses av ändringar i PR:s källgren, om det inte finns några push-incheckningar vars meddelanden eller beskrivningar innehåller [skip ci] (eller någon av dess varianter). Om minst en push-överföring innehåller [skip ci]körs inte pipelines.

När du har sammanfogat PR kör Azure Pipelines slutligen CI-pipelines som utlöses av push-meddelanden till målgrenen, om kopplingsincheckningens meddelande eller beskrivning inte innehåller [skip ci] (eller någon av dess varianter).

Skyddade förgreningar

Du kan köra en valideringsversion med varje inchecknings- eller pull-begäran som riktar sig till en gren och till och med förhindra att pull-begäranden slås samman tills en valideringsversion lyckas.

För att konfigurera obligatoriska valideringsversioner för en GitHub-lagringsplats måste du vara dess ägare, en medarbetare med administratörsrollen eller en GitHub-organisationsmedlem med skrivrollen.

  1. Skapa först en pipeline för lagringsplatsen och skapa den minst en gång så att dess status publiceras på GitHub, vilket gör GitHub medveten om pipelinens namn.

  2. Följ sedan GitHubs dokumentation för att konfigurera skyddade grenar i lagringsplatsens inställningar.

    För statuskontrollen väljer du namnet på din pipeline i listan Statuskontroller .

    Statuskontroll för GitHub-pipeline

Viktigt!

Om pipelinen inte visas i den här listan kontrollerar du följande:

Bidrag från externa källor

Om din GitHub-lagringsplats är öppen källkod kan du göra ditt Azure DevOps-projekt offentligt så att vem som helst kan visa pipelinens byggresultat, loggar och testresultat utan att logga in. När användare utanför organisationen förgrenar lagringsplatsen och skickar pull-begäranden kan de visa status för byggen som automatiskt verifierar dessa pull-begäranden.

Tänk på följande när du använder Azure Pipelines i ett offentligt projekt när du tar emot bidrag från externa källor.

Åtkomstbegränsningar

Tänk på följande åtkomstbegränsningar när du kör pipelines i offentliga Azure DevOps-projekt:

  • Hemligheter: Som standard görs hemligheter som är associerade med din pipeline inte tillgängliga för validering av pull-begäranden av gafflar. Se Verifiera bidrag från förgreningar.
  • Åtkomst mellan projekt: Alla pipelines i ett offentligt Azure DevOps-projekt körs med en åtkomsttoken begränsad till projektet. Pipelines i ett offentligt projekt kan komma åt resurser som att skapa artefakter eller testa resultat endast inom projektet och inte i andra projekt i Azure DevOps-organisationen.
  • Azure Artifacts-paket: Om dina pipelines behöver åtkomst till paket från Azure Artifacts måste du uttryckligen ge behörighet till Project Build Service-kontot för att få åtkomst till paketflödena.

Bidrag från gafflarna

Viktigt!

De här inställningarna påverkar säkerheten för din pipeline.

När du skapar en pipeline utlöses den automatiskt för pull-begäranden från förgreningar på lagringsplatsen. Du kan ändra det här beteendet genom att noga överväga hur det påverkar säkerheten. Så här aktiverar eller inaktiverar du det här beteendet:

  1. Gå till ditt Azure DevOps-projekt. Välj Pipelines, leta upp din pipeline och välj Redigera.
  2. Välj fliken Utlösare . När du har aktiverat utlösaren för pull-begäran aktiverar eller inaktiverar du kryssrutan Skapa pull-begäranden från förgreningar för den här lagringsplatsen .

Som standard med GitHub-pipelines görs hemligheter som är associerade med bygg-pipelinen inte tillgängliga för pull-begärandeversioner av gafflar. Dessa hemligheter är aktiverade som standard med GitHub Enterprise Server-pipelines. Hemligheter är:

Om du vill kringgå den här försiktighetsåtgärden i GitHub-pipelines aktiverar du kryssrutan Gör hemligheter tillgängliga för förgreningsversioner . Tänk på den här inställningens effekt på säkerheten.

Kommentar

När du aktiverar förgreningsversioner för åtkomst till hemligheter begränsar Azure Pipelines som standard den åtkomsttoken som används för förgreningsversioner. Den har mer begränsad åtkomst till öppna resurser än en vanlig åtkomsttoken. Om du vill ge förgreningsversioner samma behörigheter som vanliga versioner aktiverar du inställningen Skapa förgreningsversioner med samma behörigheter som vanliga versioner .

Mer information finns i Lagringsplatsskydd – förgreningar.

Du kan definiera centralt hur pipelines skapar PR från förgrenade GitHub-lagringsplatser med hjälp av kontrollen Begränsa bygghämtningsbegäranden från förgrenade GitHub-lagringsplatser . Den är tillgänglig på organisations- och projektnivå. Du kan välja att:

  • Inaktivera pull-begäranden från förgrenade lagringsplatser
  • Skapa pull-begäranden från förgrenade lagringsplatser på ett säkert sätt
  • Anpassa regler för att skapa pull-begäranden från förgrenade lagringsplatser

Skärmbild av centraliserade kontrollinställningar för hur pipelines skapar PR från förgrenade GitHub-lagringsplatser.

Från och med Sprint 229, för att förbättra säkerheten för dina pipelines, skapar Azure Pipelines inte längre automatiskt pull-begäranden från förgrenade GitHub-lagringsplatser. För nya projekt och organisationer är standardvärdet för inställningen Begränsa bygghämtningsbegäranden från förgrenade GitHub-lagringsplatser Inaktivera att skapa pull-begäranden från förgrenade lagringsplatser.

När du väljer alternativet Skapa pull-begäranden på ett säkert sätt från förgrenade lagringsplatser kan inte alla pipelines, organisationen eller hela projektet göra hemligheter tillgängliga för versioner av PR:er från förgrenade lagringsplatser, inte göra dessa versioner har samma behörigheter som vanliga versioner och måste utlösas av en PR-kommentar. Projekt kan fortfarande besluta att inte tillåta att pipelines skapar sådana prs.

När du väljer alternativet Anpassa kan du definiera hur du begränsar pipelineinställningarna. Du kan till exempel se till att alla pipelines kräver en kommentar för att skapa en PR från en förgrenad GitHub-lagringsplats, när PR tillhör icke-teammedlemmar och icke-deltagare. Men du kan välja att tillåta dem att göra hemligheter tillgängliga för sådana versioner. Projekt kan besluta att inte tillåta att pipelines skapar sådana prs eller att skapa dem på ett säkert sätt eller ha ännu mer restriktiva inställningar än vad som anges på organisationsnivå.

Kontrollen är inaktiverad för befintliga organisationer. Från och med september 2023 har nya organisationer på ett säkert sätt byggt pull-begäranden från förgrenade lagringsplatser aktiverade som standard.

Viktiga säkerhetsöverväganden

En GitHub-användare kan förgrena lagringsplatsen, ändra den och skapa en pull-begäran för att föreslå ändringar i lagringsplatsen. Den här pull-begäran kan innehålla skadlig kod som ska köras som en del av den utlösta versionen. Sådan kod kan orsaka skada på följande sätt:

  • Läcka hemligheter från din pipeline. För att minska den här risken ska du inte aktivera kryssrutan Gör hemligheter tillgängliga för förgreningsversioner om lagringsplatsen är offentlig eller ej betrodda användare kan skicka pull-begäranden som automatiskt utlöser byggen. Det här alternativet är inaktiverat som standard.

  • Kompromettera datorn som kör agenten för att stjäla kod eller hemligheter från andra pipelines. Så här åtgärdar du detta:

    • Använd en Microsoft-värdbaserad agentpool för att skapa pull-begäranden från förgreningar. Microsoft-värdbaserade agentdatorer tas omedelbart bort när de har slutfört en version, så det finns ingen bestående inverkan om de komprometteras.

    • Om du måste använda en lokalt installerad agent ska du inte lagra några hemligheter eller utföra andra versioner och versioner som använder hemligheter på samma agent, såvida inte lagringsplatsen är privat och du litar på pull-begärandeskapare.

Kommentarsutlösare

Lagringsplatsens medarbetare kan kommentera en pull-begäran om att manuellt köra en pipeline. Här följer några vanliga orsaker till varför du kanske vill göra detta:

  • Du kanske inte vill skapa pull-begäranden automatiskt från okända användare förrän ändringarna kan granskas. Du vill att en av dina teammedlemmar först ska granska sin kod och sedan köra pipelinen. Detta används ofta som ett säkerhetsmått när du skapar kod från förgrenade lagringsplatser.
  • Du kanske vill köra en valfri testsvit eller en valideringsversion till.

Om du vill aktivera kommentarsutlösare måste du följa följande två steg:

  1. Aktivera utlösare för pull-begäranden för din pipeline och se till att du inte exkluderade målgrenen.
  2. I Azure Pipelines-webbportalen redigerar du din pipeline och väljer Fler åtgärder, Utlösare. Under Validering av pull-begäran aktiverar du sedan Kräv en teammedlems kommentar innan du skapar en pull-begäran.
    • Välj På alla pull-begäranden för att kräva en teammedlems kommentar innan du skapar en pull-begäran. Med det här arbetsflödet granskar en teammedlem pull-begäran och utlöser bygget med en kommentar när pull-begäran anses vara säker.
    • Välj Endast vid pull-begäranden från icke-teammedlemmar för att kräva en gruppmedlems kommentar endast när en PR görs av en icke-teammedlem. I det här arbetsflödet behöver en gruppmedlem inte en sekundär teammedlems granskning för att utlösa en version.

Med dessa två ändringar utlöses inte valideringsversionen av pull-begäranden automatiskt, såvida inte endast pull-begäranden från icke-teammedlemmar väljs och PR görs av en teammedlem. Endast lagringsplatsens ägare och medarbetare med behörigheten Skriv kan utlösa bygget genom att kommentera pull-begäran med /AzurePipelines run eller /AzurePipelines run <pipeline-name>.

Följande kommandon kan utfärdas till Azure Pipelines i kommentarer:

Command Result
/AzurePipelines help Visa hjälp för alla kommandon som stöds.
/AzurePipelines help <command-name> Visa hjälp för det angivna kommandot.
/AzurePipelines run Kör alla pipelines som är associerade med den här lagringsplatsen och vars utlösare inte utesluter den här pull-begäran.
/AzurePipelines run <pipeline-name> Kör den angivna pipelinen om inte utlösarna utesluter den här pull-begäran.

Kommentar

För korthet kan du kommentera med i /azp stället för /AzurePipelines.

Viktigt!

Svar på dessa kommandon visas endast i pull-begärandediskussionen om din pipeline använder Azure Pipelines GitHub-appen.

Felsöka utlösare för pull-begärandekommenterar

Om du har nödvändiga lagringsplatsbehörigheter, men pipelines inte utlöses av dina kommentarer, kontrollerar du att ditt medlemskap är offentligt i lagringsplatsens organisation eller lägger direkt till dig själv som samarbetspartner för lagringsplatsen. Pipelines kan inte se medlemmar i den privata organisationen om de inte är direkta medarbetare eller tillhör ett team som är en direkt medarbetare. Du kan ändra ditt GitHub-organisationsmedlemskap från privat till offentligt här (ersätt Your-Organization med ditt organisationsnamn): https://github.com/orgs/Your-Organization/people.

Informationskörningar

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

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

Skärmbild av en körning av en informationspipeline.

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

  • Status är Canceled
  • Varaktigheten är < 1s
  • Körningsnamnet innehåller någon av följande texter:
    • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
    • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
    • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
    • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
  • Körningsnamnet innehåller vanligtvis BitBucket/GitHub-felet som gjorde att YAML-pipelinebelastningen misslyckades
  • Inga steg/jobb/steg

Läs mer om informationskörningar.

Utcheckning

När en pipeline utlöses hämtar Azure Pipelines källkoden från Git-lagringsplatsen för Azure Repos. Du kan styra olika aspekter av hur detta sker.

Kommentar

När du inkluderar ett utcheckningssteg i pipelinen kör vi följande kommando: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Om detta inte uppfyller dina behov kan du välja att exkludera den inbyggda utcheckningen och checkout: none sedan använda en skriptuppgift för att utföra en egen utcheckning.

Önskad version av Git

Windows-agenten levereras med en egen kopia av Git. Om du föredrar att ange din egen Git i stället för att använda den medföljande kopian anger du System.PreferGitFromPath till true. Den här inställningen gäller alltid för icke-Windows-agenter.

Sökväg till utcheckning

Om du checkar ut en enda lagringsplats checkas källkoden som standard ut till en katalog med namnet s. För YAML-pipelines kan du ändra detta genom att checkout ange med en path. Den angivna sökvägen är relativ till $(Agent.BuildDirectory). Till exempel: om värdet för utcheckningssökvägen är mycustompath och $(Agent.BuildDirectory) är C:\agent\_work\1, checkas källkoden ut till C:\agent\_work\1\mycustompath.

Om du använder flera checkout steg och checkar ut flera lagringsplatser och inte uttryckligen anger mappen med , pathplaceras varje lagringsplats i en undermapp s med namnet efter lagringsplatsen. Om du till exempel checkar ut två lagringsplatser med namnet tools och code, checkas källkoden ut till C:\agent\_work\1\s\tools och C:\agent\_work\1\s\code.

Observera att värdet för utcheckningssökvägen inte kan anges för att gå upp några katalognivåer ovanför $(Agent.BuildDirectory), så path\..\anotherpath resulterar i en giltig utcheckningssökväg (d.v.s. C:\agent\_work\1\anotherpath), men ett värde som ..\invalidpath inte gör det (dvs. C:\agent\_work\invalidpath).

Du kan konfigurera inställningen path i utcheckningssteget i din pipeline.

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

Submodules

Du kan konfigurera inställningen submodules i utcheckningssteget i pipelinen om du vill ladda ned filer från undermoduler.

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

Bygg-pipelinen checkar ut dina Git-undermoduler så länge de är:

  • Oautentiserad: En offentlig, oautentiserad lagringsplats utan autentiseringsuppgifter som krävs för att klona eller hämta.

  • Autentiserade:

    • Finns i samma projekt som Git-lagringsplatsen för Azure Repos som anges ovan. Samma autentiseringsuppgifter som används av agenten för att hämta källorna från huvudlagringsplatsen används också för att hämta källorna för undermoduler.

    • Har lagts till med hjälp av en URL i förhållande till huvudlagringsplatsen. Till exempel

      • Den här skulle checkas ut: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        I det här exemplet refererar undermodulen till en lagringsplats (FabrikamFiber) i samma Azure DevOps-organisation, men i ett annat projekt (FabrikamFiberProject). Samma autentiseringsuppgifter som används av agenten för att hämta källorna från huvudlagringsplatsen används också för att hämta källorna för undermoduler. Detta kräver att jobbåtkomsttoken har åtkomst till lagringsplatsen i det andra projektet. Om du har begränsat token för jobbåtkomst enligt beskrivningen i avsnittet ovan kan du inte göra det. Du kan tillåta att jobbåtkomsttoken får åtkomst till lagringsplatsen i det andra projektet genom att antingen (a) uttryckligen bevilja åtkomst till project build-tjänstkontot i det andra projektet eller (b) med hjälp av åtkomsttoken med samlingsomfång i stället för projektomfångstoken för hela organisationen. Mer information om dessa alternativ och deras säkerhetskonsekvenser finns i Åtkomstlagringsplatser, artefakter och andra resurser.

      • Den här skulle inte checkas ut: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternativ till att använda alternativet Checkout-undermoduler

I vissa fall kan du inte använda alternativet Checkout-undermoduler . Du kan ha ett scenario där en annan uppsättning autentiseringsuppgifter behövs för att komma åt undermodulerna. Detta kan till exempel inträffa om huvudlagringsplatsen och undermodullagringsplatserna inte lagras i samma Azure DevOps-organisation, eller om din jobbåtkomsttoken inte har åtkomst till lagringsplatsen i ett annat projekt.

Om du inte kan använda alternativet Checkout-undermoduler kan du i stället använda ett anpassat skriptsteg för att hämta undermoduler. Hämta först en personlig åtkomsttoken (PAT) och prefixet med pat:. Därefter base64-koda den här prefixsträngen för att skapa en grundläggande autentiseringstoken. Lägg slutligen till det här skriptet i pipelinen:

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

Ersätt "<BASE64_ENCODED_STRING>" med din Base64-kodade "pat:token"-sträng.

Använd en hemlig variabel i projektet eller bygg-pipelinen för att lagra den grundläggande autentiseringstoken som du genererade. Använd variabeln för att fylla i hemligheten i git-kommandot ovan.

Kommentar

F: Varför kan jag inte använda en Git-autentiseringshanterare på agenten? S: Lagring av autentiseringsuppgifterna för undermodulen i en Git-autentiseringshanterare som är installerad på din privata byggagent är vanligtvis inte effektivt eftersom autentiseringshanteraren kan uppmana dig att ange autentiseringsuppgifterna igen när undermodulen uppdateras. Detta är inte önskvärt under automatiserade versioner när användarinteraktion inte är möjligt.

Synkroniseringstaggar

Viktigt!

Funktionen för synkroniseringstaggar stöds i Azure Repos Git med Azure DevOps Server 2022.1 och senare.

I utcheckningssteget --tags används alternativet när innehållet på en Git-lagringsplats hämtas. Detta gör att servern hämtar alla taggar samt alla objekt som pekas på av dessa taggar. Detta ökar tiden för att köra aktiviteten i en pipeline, särskilt om du har en stor lagringsplats med ett antal taggar. Dessutom synkroniserar utcheckningssteget taggar även när du aktiverar det grunda hämtningsalternativet, vilket möjligen kan besegra dess syfte. För att minska mängden data som hämtas eller hämtas från en Git-lagringsplats har Microsoft lagt till ett nytt alternativ för att checka ut för att kontrollera beteendet för synkroniseringstaggar. Det här alternativet är tillgängligt både i klassiska pipelines och YAML-pipelines.

Om du vill synkronisera taggar när du checkar ut en lagringsplats kan konfigureras i YAML genom att ange fetchTags egenskapen och i användargränssnittet genom att konfigurera inställningen Synkroniseringstaggar .

Du kan konfigurera inställningen fetchTags i utcheckningssteget i din pipeline.

Ange egenskapen för fetchTags att konfigurera inställningen i YAML.

steps:
- checkout: self
  fetchTags: true

Du kan också konfigurera den här inställningen med alternativet Synkroniseringstaggar i användargränssnittet för pipelineinställningar.

  1. Redigera YAML-pipelinen och välj Fler åtgärder, Utlösare.

    Skärmbild av menyn för fler utlösare.

  2. Välj YAML, Hämta källor.

    Skärmbild av Hämta källor.

  3. Konfigurera inställningen Synkronisera taggar.

    Skärmbild av inställningen Synkronisera taggar.

Kommentar

Om du uttryckligen anger fetchTags i steget checkout prioriteras den inställningen framför inställningen som konfigurerats i användargränssnittet för pipelineinställningar.

Standardbeteende

  • För befintliga pipelines som skapats före lanseringen av Azure DevOps sprint 209, som släpptes i september 2022, förblir standardvärdet för synkroniseringstaggar detsamma som det befintliga beteendet innan alternativen för synkroniseringstaggar lades till, vilket är true.
  • För nya pipelines som skapats efter Azure DevOps sprint version 209 är falsestandardinställningen för synkroniseringstaggar .

Kommentar

Om du uttryckligen anger fetchTags i steget checkout prioriteras den inställningen framför inställningen som konfigurerats i användargränssnittet för pipelineinställningar.

Ytlig hämtning

Du kanske vill begränsa hur långt tillbaka i historiken som ska laddas ned. I praktiken resulterar detta i git fetch --depth=n. Om lagringsplatsen är stor kan det här alternativet göra bygg-pipelinen mer effektiv. Lagringsplatsen kan vara stor om den har använts länge och har en betydande historik. Det kan också vara stort om du har lagt till och senare tagit bort stora filer.

Viktigt!

Nya pipelines som skapats efter uppdateringen av Azure DevOps sprint 209 i september 2022 har Shallow-hämtning aktiverat som standard och konfigurerats med ett djup på 1. Tidigare var standardvärdet inte för ytlig hämtning. Om du vill kontrollera din pipeline kan du visa inställningen Shallow fetch i UI för pipelineinställningar enligt beskrivningen i följande avsnitt.

Du kan konfigurera inställningen fetchDepth i utcheckningssteget i din pipeline.

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

Du kan också konfigurera hämtningsdjup genom att ange alternativet Grunt djup i pipelineinställningarnas användargränssnitt.

  1. Redigera YAML-pipelinen och välj Fler åtgärder, Utlösare.

    Skärmbild av menyn för fler utlösare.

  2. Välj YAML, Hämta källor.

    Skärmbild av Hämta källor.

  3. Konfigurera inställningen Grunt hämtning. Avmarkera Grunt hämtning för att inaktivera ytlig hämtning, eller markera kryssrutan och ange ett djup för att aktivera ytlig hämtning.

    Skärmbild av alternativ.

Kommentar

Om du uttryckligen anger fetchDepth i steget checkout prioriteras den inställningen framför inställningen som konfigurerats i användargränssnittet för pipelineinställningar. Inställningen fetchDepth: 0 hämtar all historik och åsidosätter inställningen Shallow fetch .

I dessa fall kan det här alternativet hjälpa dig att spara nätverks- och lagringsresurser. Det kan också spara tid. Anledningen till att det inte alltid sparar tid är att servern i vissa situationer kan behöva ägna tid åt att beräkna incheckningarna för att ladda ned för det djup som du anger.

Kommentar

När pipelinen startas matchas grenen som ska skapas till ett inchecknings-ID. Sedan hämtar agenten grenen och checkar ut önskad incheckning. Det finns ett litet fönster mellan när en gren matchas till ett inchecknings-ID och när agenten utför utcheckningen. Om grenen uppdateras snabbt och du anger ett mycket litet värde för ytlig hämtning kanske incheckningen inte finns när agenten försöker checka ut den. Om det händer ökar du inställningen för grunt hämtningsdjup.

Synkronisera inte källor

Du kanske vill hoppa över att hämta nya incheckningar. Det här alternativet kan vara användbart i de fall då du vill:

  • Git-init, konfiguration och hämtning med dina egna anpassade alternativ.

  • Använd en byggpipeline för att bara köra automatisering (till exempel vissa skript) som inte är beroende av kod i versionskontroll.

Du kan konfigurera inställningen Synkronisera inte källor i utcheckningssteget i din pipeline genom att ange checkout: none.

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

Kommentar

När du använder det här alternativet hoppar agenten också över att köra Git-kommandon som rensar lagringsplatsen.

Rensa version

Du kan utföra olika former av rensning av arbetskatalogen för din lokalt installerade agent innan en version körs.

I allmänhet ska du inte rensa lagringsplatsen för snabbare prestanda för dina lokalt installerade agenter. I det här fallet bör du se till att du också skapar stegvis för att få bästa möjliga prestanda genom att inaktivera alternativet Rensa för den uppgift eller det verktyg som du använder för att skapa.

Om du behöver rensa lagringsplatsen (till exempel för att undvika problem som orsakas av residualfiler från en tidigare version) finns alternativen nedan.

Kommentar

Rensning är inte effektivt om du använder en Microsoft-värdbaserad agent eftersom du får en ny agent varje gång.

Du kan konfigurera inställningen clean i utcheckningssteget i din pipeline.

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

När clean är inställt true på bygg-pipelinen utför en ångra av eventuella ändringar i $(Build.SourcesDirectory). Mer specifikt körs följande Git-kommandon innan källan hämtas.

git clean -ffdx
git reset --hard HEAD

Om du vill ha fler alternativ kan du konfigurera inställningen för workspace ett jobb.

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

Detta ger följande rena alternativ.

  • utdata: Samma åtgärd som den rena inställningen som beskrivs i föregående utcheckningsaktivitet, plus: Tar bort och återskapar $(Build.BinariesDirectory). Observera att $(Build.ArtifactStagingDirectory) och $(Common.TestResultsDirectory) alltid tas bort och återskapas före varje bygge oavsett någon av dessa inställningar.

  • resurser: Tar bort och återskapar $(Build.SourcesDirectory). Detta resulterar i att en ny lokal Git-lagringsplats initieras för varje version.

  • alla: Tar bort och återskapar $(Agent.BuildDirectory). Detta resulterar i att en ny lokal Git-lagringsplats initieras för varje version.

Etikettkällor

Du kanske vill märka dina källkodsfiler så att ditt team enkelt kan identifiera vilken version av varje fil som ingår i den färdiga versionen. Du kan också ange om källkoden ska märkas för alla versioner eller endast för lyckade versioner.

Du kan för närvarande inte konfigurera den här inställningen i YAML, men det kan du i den klassiska redigeraren. När du redigerar en YAML-pipeline kan du komma åt den klassiska redigeraren genom att välja antingen Utlösare från YAML-redigerarmenyn.

Konfigurera Git-alternativ, YAML.

I den klassiska redigeraren väljer du YAML, väljer uppgiften Hämta källor och konfigurerar sedan önskade egenskaper där.

I den klassiska redigeraren väljer du YAML > Hämta källor.

I taggformatet kan du använda användardefinierade och fördefinierade variabler som har omfånget "Alla". Till exempel:

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

De första fyra variablerna är fördefinierade. My.Variablekan definieras av dig på fliken variabler.

Bygg-pipelinen etiketterar dina källor med en Git-tagg.

Vissa byggvariabler kan ge ett värde som inte är en giltig etikett. Variabler som $(Build.RequestedFor) och $(Build.DefinitionName) kan till exempel innehålla tomt utrymme. Om värdet innehåller tomt utrymme skapas inte taggen.

När källorna har taggats av bygg-pipelinen läggs en artefakt med Git-referensen refs/tags/{tag} automatiskt till i den färdiga versionen. Detta ger ditt team ytterligare spårbarhet och ett mer användarvänligt sätt att navigera från bygget till koden som skapades. Taggen anses vara en byggartefakt eftersom den skapas av bygget. När bygget tas bort manuellt eller via en kvarhållningsprincip tas taggen också bort.

Fördefinierade variabler

När du skapar en GitHub-lagringsplats är de flesta av de fördefinierade variablerna tillgängliga för dina jobb. Men eftersom Azure Pipelines inte känner igen identiteten för en användare som gör en uppdatering i GitHub, ställs följande variabler in på systemidentitet i stället för användarens identitet:

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

Statusuppdateringar

Det finns två typer av statusar som Azure Pipelines publicerar tillbaka till GitHub – grundläggande status och GitHub-kontrollkörningar. GitHub Checks-funktioner är endast tillgängliga med GitHub Apps.

Pipelinestatusar visas på olika platser i GitHub-användargränssnittet.

  • För pr-konversationer visas de på fliken PR-konversationer.
  • För enskilda incheckningar visas de när de hovrar över statusmarkeringen efter incheckningstiden på lagringsplatsens incheckningsflik.

PAT- eller OAuth GitHub-anslutningar

För pipelines som använder PAT - eller OAuth GitHub-anslutningar publiceras statusar tillbaka till incheckningen/PR som utlöste körningen. GitHub-status-API:et används för att publicera sådana uppdateringar. Dessa statusar innehåller begränsad information: pipelinestatus (misslyckades, lyckades), URL för att länka tillbaka till bygg-pipelinen och en kort beskrivning av statusen.

Statusar för PAT- eller OAuth GitHub-anslutningar skickas endast på körningsnivå. Med andra ord kan du ha en enda status uppdaterad för en hel körning. Om du har flera jobb i en körning kan du inte publicera en separat status för varje jobb. Flera pipelines kan dock publicera separata statusar för samma incheckning.

GitHub-kontroller

För pipelines som har konfigurerats med Azure Pipelines GitHub-appen publiceras statusen tillbaka i form av GitHub-kontroller. GitHub-kontroller gör det möjligt att skicka detaljerad information om pipelinestatus och test, kodtäckning och fel. GitHub Checks-API:et finns här.

För varje pipeline som använder GitHub-appen publiceras checkar tillbaka för den övergripande körningen och varje jobb i den körningen.

GitHub tillåter tre alternativ när en eller flera kontrollkörningar misslyckas för en PR/incheckning. Du kan välja att "köra om" den enskilda kontrollen, köra om alla misslyckade kontroller för den pr/incheckningen eller köra alla kontroller igen, oavsett om de lyckades från början eller inte.

GitHub-kontroller kör igen

Om du klickar på länken "Kör igen" bredvid namnet på Check Run (Kontrollera körning) kommer Azure Pipelines att försöka köras igen som genererade Check Run (Kontrollera körning). Den resulterande körningen har samma körningsnummer och använder samma version av källkoden, konfigurationen och YAML-filen som den första versionen. Endast de jobb som misslyckades i den första körningen och eventuella beroende underordnade jobb kommer att köras igen. Om du klickar på länken "Kör om alla misslyckade kontroller" får du samma effekt. Det här är samma beteende som att klicka på "Försök köra igen" i Användargränssnittet för Azure Pipelines. Om du klickar på Kör alla kontroller igen resulterar det i en ny körning med ett nytt körningsnummer och hämtar ändringar i konfigurationen eller YAML-filen.

Begränsningar

  • För bästa prestanda rekommenderar vi högst 50 pipelines på en enda lagringsplats. För godtagbara prestanda rekommenderar vi högst 100 pipelines på en enda lagringsplats. Tiden som krävs för att bearbeta en push-överföring till en lagringsplats ökar med antalet pipelines på lagringsplatsen. När det finns push-överföring till en lagringsplats måste Azure Pipelines läsa in alla YAML-pipelines på den lagringsplatsen för att ta reda på om någon av dem behöver köras och inläsning av varje pipeline medför prestandastraff. Förutom prestandaproblem kan för många pipelines på en enda lagringsplats leda till begränsning på GitHubs sida, eftersom Azure Pipelines kan göra för många begäranden på kort tid.

  • Användningen av utökar och inkluderar mallar i en pipeline påverkar den hastighet med vilken Azure Pipelines gör GitHub API-begäranden och kan leda till begränsning på GitHubs sida. Innan du kör en pipeline måste Azure Pipelines generera den fullständiga YAML-koden, så den måste hämta alla mallfiler.

  • Azure Pipelines läser in högst 2 000 grenar från en lagringsplats till listrutor i Azure DevOps-portalen, till exempel i fönstret Välj en gren för standardgrenen för manuella och schemalagda versioner , eller när du väljer en gren när du kör en pipeline manuellt.

    Om du inte ser önskad gren i listan skriver du önskat grennamn manuellt i fältet Standardgren för manuella och schemalagda versioner .

    Om du klickar på ellipsen och öppnar dialogrutan Välj en gren och stänger den utan att välja en giltig gren från listrutan kan du se ett meddelande om att Vissa inställningar behöver uppmärksammas och att den här inställningen är obligatorisk under Standardgren för manuella och schemalagda versioner. Om du vill kringgå det här meddelandet öppnar du pipelinen igen och anger namnet direkt i fältet Standardgren för manuella och schemalagda versioner .

Vanliga frågor

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

  • Anslutningstyper: Jag är inte säker på vilken anslutningstyp jag använder för att ansluta min pipeline till GitHub.
  • Utlösare som misslyckas: Min pipeline utlöses inte när jag skickar en uppdatering till lagringsplatsen.
  • Misslyckad utcheckning: Min pipeline utlöses, men den misslyckas i utcheckningssteget.
  • Fel version: Min pipeline körs, men den använder en oväntad version av källan/YAML.
  • Statusuppdateringar saknas: Mina GitHub-PR:er blockeras eftersom Azure Pipelines inte rapporterar någon statusuppdatering.

Anslutningstyper

Hur vet jag vilken typ av GitHub-anslutning jag använder för min pipeline för att felsöka utlösare?

Felsökning av problem med utlösare beror mycket på vilken typ av GitHub-anslutning du använder i din pipeline. Det finns två sätt att fastställa typen av anslutning – från GitHub och från Azure Pipelines.

  • Från GitHub: Om en lagringsplats har konfigurerats för att använda GitHub-appen blir statusen för PR:er och incheckningar Kontrollera körningar. Om lagringsplatsen har Azure Pipelines konfigurerat med OAuth- eller PAT-anslutningar är statusarna statusen "gamla" statusformat. Ett snabbt sätt att avgöra om statusarna är Check Runs eller enkla statusar är att titta på fliken "konversation" på en GitHub PR.

    • Om länken "Information" omdirigeras till fliken Kontroller är det en Kontrollera körning och lagringsplatsen använder appen.
    • Om länken "Information" omdirigeras till Azure DevOps-pipelinen är statusen "gammal stil" och lagringsplatsen använder inte appen.

  • Från Azure Pipelines: Du kan också fastställa typen av anslutning genom att granska pipelinen i Användargränssnittet för Azure Pipelines. Öppna redigeraren för pipelinen. Välj Utlösare för att öppna den klassiska redigeraren för pipelinen. Välj sedan fliken YAML och sedan steget Hämta källor . Du ser en banderoll som har behörighet med hjälp av anslutningen: som anger tjänstanslutningen som användes för att integrera pipelinen med GitHub. Namnet på tjänstanslutningen är en hyperlänk. Välj den för att navigera till egenskaperna för tjänstanslutningen. Egenskaperna för tjänstanslutningen anger vilken typ av anslutning som används:

    • Azure Pipelines-appen anger GitHub-appanslutning
    • oauth anger OAuth-anslutning
    • personalaccesstoken anger PAT-autentisering

Hur växlar jag min pipeline för att använda GitHub-appen i stället för OAuth?

Att använda en GitHub-app i stället för OAuth- eller PAT-anslutning är den rekommenderade integreringen mellan GitHub och Azure Pipelines. Om du vill växla till GitHub-appen följer du dessa steg:

  1. Navigera hit och installera appen i GitHub-organisationen för din lagringsplats.
  2. Under installationen omdirigeras du till Azure DevOps för att välja en Azure DevOps-organisation och ett projekt. Välj den organisation och det projekt som innehåller den klassiska bygg-pipeline som du vill använda appen för. Det här valet associerar GitHub App-installationen med din Azure DevOps-organisation. Om du väljer fel kan du besöka den här sidan för att avinstallera GitHub-appen från din GitHub-organisation och börja om.
  3. På nästa sida som visas behöver du inte fortsätta att skapa en ny pipeline.
  4. Redigera din pipeline genom att gå till sidan Pipelines (t.ex. https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), välja din pipeline och klicka på Redigera.
  5. Om det här är en YAML-pipeline väljer du menyn Utlösare för att öppna den klassiska redigeraren.
  6. Välj steget Hämta källor i pipelinen.
  7. I det gröna fältet med texten "Auktoriserad med anslutning" väljer du "Ändra" och väljer GitHub App-anslutningen med samma namn som GitHub-organisationen där du installerade appen.
  8. I verktygsfältet väljer du "Spara och köa" och sedan "Spara och köa". Välj länken till pipelinekörningen som stod i kö för att se till att den lyckas.
  9. Skapa (eller stäng och öppna) en pull-begäran på GitHub-lagringsplatsen för att kontrollera att en version har placerats i kö i avsnittet "Checkar".

Varför visas inte en GitHub-lagringsplats som jag kan välja i Azure Pipelines?

Beroende på autentiseringstyp och ägarskap för lagringsplatsen krävs specifika behörigheter.

När jag väljer en lagringsplats när pipelinen skapas får jag felmeddelandet "Lagringsplatsen {repo-name} används med Azure Pipelines GitHub-appen i en annan Azure DevOps-organisation."

Det innebär att lagringsplatsen redan är associerad med en pipeline i en annan organisation. CI- och PR-händelser från den här lagringsplatsen fungerar inte eftersom de levereras till den andra organisationen. Här följer de steg du bör vidta för att ta bort mappningen till den andra organisationen innan du fortsätter att skapa en pipeline.

  1. Öppna en pull-begäran på din GitHub-lagringsplats och gör kommentaren /azp where. Detta rapporterar tillbaka den Azure DevOps-organisation som lagringsplatsen är mappad till.

  2. Om du vill ändra mappningen avinstallerar du appen från GitHub-organisationen och installerar om den. När du installerar om den måste du välja rätt organisation när du omdirigeras till Azure DevOps.

Felutlösare

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

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

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

    Användargränssnitt för pipelineinställningar.

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

    Åsidosätt YAML-utlösare härifrån.

  • Använder du GitHub-appanslutningen för att ansluta pipelinen till GitHub? Se Anslutningstyper för att fastställa vilken typ av anslutning du har. Om du använder en GitHub-appanslutning följer du dessa steg:

    • Är mappningen korrekt konfigurerad mellan GitHub och Azure DevOps? Öppna en pull-begäran på din GitHub-lagringsplats och gör kommentaren /azp where. Detta rapporterar tillbaka den Azure DevOps-organisation som lagringsplatsen är mappad till.

      • Om inga organisationer har konfigurerats för att skapa den här lagringsplatsen med hjälp av appen går du till https://github.com/<org_name>/<repo_name>/settings/installations och slutför konfigurationen av appen.

      • Om en annan Azure DevOps-organisation rapporteras har någon redan upprättat en pipeline för den här lagringsplatsen i en annan organisation. Vi har för närvarande begränsningen att vi bara kan mappa en GitHub-lagringsplats till en enda DevOps-organisation. Endast pipelines i den första Azure DevOps-organisationen kan utlösas automatiskt. Om du vill ändra mappningen avinstallerar du appen från GitHub-organisationen och installerar om den. När du installerar om den måste du välja rätt organisation när du omdirigeras till Azure DevOps.

  • Använder du OAuth eller PAT för att ansluta pipelinen till GitHub? Se Anslutningstyper för att fastställa vilken typ av anslutning du har. Om du använder en GitHub-anslutning följer du dessa steg:

    1. OAuth- och PAT-anslutningar förlitar sig på webhooks för att kommunicera uppdateringar till Azure Pipelines. I GitHub navigerar du till inställningarna för din lagringsplats och sedan till Webhooks. Kontrollera att webhooks finns. Vanligtvis bör du se tre webhooks – push, pull_request och issue_comment. Om du inte gör det måste du återskapa tjänstanslutningen och uppdatera pipelinen för att använda den nya tjänstanslutningen.

    2. Välj var och en av webhooksna i GitHub och kontrollera att nyttolasten som motsvarar användarens incheckning finns och har skickats till Azure DevOps. Du kan se ett fel här om händelsen inte kunde kommuniceras med Azure DevOps.

  • Trafiken från Azure DevOps kan begränsas av GitHub. När Azure Pipelines tar emot ett meddelande från GitHub försöker de kontakta GitHub och hämta mer information om lagringsplatsen och YAML-filen. Om du har en lagringsplats med ett stort antal uppdateringar och pull-begäranden kan det här anropet misslyckas på grund av en sådan begränsning. I det här fallet kan du se om du kan minska frekvensen för versioner med hjälp av batchbearbetning eller striktare sökvägs-/grenfilter.

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

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

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

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

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

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

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

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

Gå först igenom felsökningsstegen i föregående fråga och följ sedan följande ytterligare steg:

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

  • Har du en fördröjning i bearbetningen av push- eller PR-händelser? Du kan vanligtvis kontrollera en fördröjning genom att se om problemet är specifikt för en enda pipeline eller är gemensamt för alla pipelines eller lagringsplatser i projektet. Om en push- eller PR-uppdatering till någon av lagringsplatserna uppvisar det här symptomet kan det uppstå fördröjningar i bearbetningen av uppdateringshändelserna. Här följer några orsaker till varför en fördröjning kan inträffa:

    • Vi upplever ett avbrott i tjänsten på vår statussida. Om statussidan visar ett problem måste vårt team redan ha börjat arbeta med det. Kontrollera sidan ofta för att få uppdateringar om problemet.
    • Lagringsplatsen innehåller för många YAML-pipelines. För bästa prestanda rekommenderar vi högst 50 pipelines på en enda lagringsplats. För godtagbara prestanda rekommenderar vi högst 100 pipelines på en enda lagringsplats. Ju fler pipelines det finns, desto långsammare bearbetning av en push-överföring till lagringsplatsen. När det finns push-överföring till en lagringsplats måste Azure Pipelines läsa in alla YAML-pipelines på den lagringsplatsen för att ta reda på om någon av dem behöver köras, och varje ny pipeline medför prestandastraff.

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

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

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

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

Misslyckad utcheckning

Jag ser följande fel i loggfilen under utcheckningssteget. Hur åtgärdar jag detta?

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

Detta kan orsakas av ett avbrott i GitHub. Försök att komma åt lagringsplatsen i GitHub och se till att du kan.

Fel version

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

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

Statusuppdateringar saknas

Min PR i GitHub är blockerad eftersom Azure Pipelines inte uppdaterade statusen.

Det kan vara ett tillfälligt fel som resulterade i att Azure DevOps inte kunde kommunicera med GitHub. Försök checka in GitHub igen om du använder GitHub-appen. Eller gör en trivial uppdatering av PR för att se om problemet kan lösas.