Skapa GitHub-lagringsplatser

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.

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

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

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:

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

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.

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

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.

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:

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.

trigger:
- main
- releases/*

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

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

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

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

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

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

# A pipeline with no CI trigger
trigger: none

Hoppar över CI för enskilda incheckningar

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

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

Använda utlösartypen i villkor

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

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

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

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

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

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

Jokertecken

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

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

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

PR-utlösare

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

pr:
- main
- releases/*

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

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

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

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

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

# no PR triggers
pr: none

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 .

   

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
• Verifiera bidrag från förgreningar
• Viktiga säkerhetsöverväganden

Å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

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:

• En säkerhetstoken med åtkomst till din GitHub-lagringsplats.
• Dessa objekt, om din pipeline använder dem:
  • Autentiseringsuppgifter för tjänstanslutning
  • Filer från biblioteket för säkra filer
  • Skapa variabler som markerats som hemlighet

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.

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

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:

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.

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.

Ö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

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

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.

Synkroniseringstaggar

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 .

steps:
- checkout: self
  fetchTags: true

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 .

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.

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

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.

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.

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

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.

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

git clean -ffdx
git reset --hard HEAD

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

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.

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.

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.

• Om du använder GitHub-appen läser du GitHub App-autentisering.
• Om du använder OAuth läser du OAuth-autentisering.
• Om du använder PAT kan du läsa autentisering med personlig åtkomsttoken (PAT).

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.

  

  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.

  

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

Relaterade artiklar

• Schemalagda utlösare
• Utlösare för pipeline-slutförande