Share via

Pijplijnopties voor Git-opslagplaatsen

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Tijdens het bewerken van een pijplijn die gebruikmaakt van een Git-opslagplaats, in een Azure DevOps-project, GitHub, GitHub Enterprise Server, Bitbucket Cloud of een andere Git-opslagplaats, hebt u de volgende opties.

Functie Azure-pipelines Azure DevOps Server 2019 en hoger TFS 2018
Vertakking Ja Ja Ja
Hygiëne Ja Ja Ja
Label- of labelbronnen Project; Alleen klassiek Teamproject Teamproject
Buildstatus van rapport Ja Ja Ja
Submodules uitchecken Ja Ja Ja
Bestanden van LFS uitchecken Ja Ja Ja
Een tweede opslagplaats klonen Ja Ja Ja
Bronnen niet synchroniseren Ja Ja Ja
Ondiep ophalen Ja Ja Ja

Notitie

Klik op Geavanceerde instellingen in de taak Bronnen ophalen om een aantal van de bovenstaande opties weer te geven.

Vertakking

Dit is de vertakking die u als standaard wilt gebruiken wanneer u deze build handmatig in de wachtrij zet. Als u een geplande trigger voor de build instelt, is dit de vertakking van waaruit uw build de meest recente bronnen krijgt. De standaardbranch heeft geen invloed wanneer de build wordt geactiveerd via continue integratie (CI). Meestal stelt u dit in op dezelfde als de standaardvertakking van de opslagplaats (bijvoorbeeld 'master').

De lokale opslagplaats op de agent opschonen

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

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

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

Notitie

Schoonmaken is niet effectief als u een door Microsoft gehoste agent gebruikt, omdat u elke keer een nieuwe agent krijgt. Wanneer u zelf-hostende agents gebruikt, afhankelijk van de configuratie van uw agentspools, krijgt u mogelijk een nieuwe agent voor volgende pijplijnuitvoeringen (of fasen of taken in dezelfde pijplijn), dus het niet opschonen is geen garantie dat volgende uitvoeringen, taken of fasen toegang hebben tot uitvoer van eerdere uitvoeringen, taken of fasen.

Notitie

Wanneer u zelf-hostende agents gebruikt, afhankelijk van de configuratie van uw agentspools, krijgt u mogelijk een nieuwe agent voor volgende pijplijnuitvoeringen (of fasen of taken in dezelfde pijplijn), dus het niet opschonen is geen garantie dat volgende uitvoeringen, taken of fasen toegang hebben tot uitvoer van eerdere uitvoeringen, taken of fasen. U kunt Build-artefacten gebruiken om uitvoer van een pijplijnuitvoering, fase of taak te delen met volgende uitvoeringen, fasen of taken.

Azure Pipelines, Azure DevOps Server 2019 en hoger

Er zijn verschillende schone opties beschikbaar voor YAML-pijplijnen.

  • De checkout stap heeft een clean optie. Wanneer deze is ingesteld true, wordt de pijplijn uitgevoerd execute git clean -ffdx && git reset --hard HEAD voordat de opslagplaats wordt opgehaald. Zie Uitchecken voor meer informatie.
  • De workspace instelling voor job heeft meerdere schone opties (uitvoer, resources, alle). Zie Werkruimte voor meer informatie.
  • De gebruikersinterface voor pijplijninstellingen heeft een schone instelling. Als deze instelling is ingesteld op true, is dit equivalent van het clean: true opgeven voor elke checkout stap in uw pijplijn. De instelling Opschonen configureren:

    1. Bewerk uw pijplijn, kies ...en selecteer Triggers.

      Triggers bewerken.

    2. Selecteer YAML, Bronnen ophalen en configureer de gewenste instelling Opschonen . De standaardwaarde is waar.

      Schone instelling.

Als u schone instellingen wilt overschrijven bij het handmatig uitvoeren van een pijplijn, kunt u runtimeparameters gebruiken. In het volgende voorbeeld wordt een runtimeparameter gebruikt voor het configureren van de schone instelling voor uitchecken.

parameters:
- name: clean
  displayName: Checkout clean
  type: boolean
  default: true
  values:
  - false
  - true

trigger:
- main

pool: FabrikamPool
#  vmImage: 'ubuntu-latest'

steps:
- checkout: self
  clean: ${{ parameters.clean }}

De standaardinstelling is ingesteld true op clean maar kan worden overschreven wanneer u de pijplijn handmatig uitvoert door het selectievakje Uitchecken uit te schakelen dat is toegevoegd voor de runtimeparameter.

Labelbronnen

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

Notitie

U kunt deze functie alleen gebruiken wanneer de bronopslagplaats in uw build een GitHub-opslagplaats of een Git- of TFVC-opslagplaats is vanuit uw project.

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

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

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

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

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

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

Buildstatus rapporteren (Azure Pipelines, TFS 2018 en hoger)

U hebt de mogelijkheid om uw team een weergave te geven van de buildstatus vanuit uw externe bronopslagplaats.

Als uw bronnen zich in een Git-opslagplaats voor Azure-opslagplaatsen in uw project bevinden, wordt met deze optie een badge weergegeven op de codepagina om aan te geven of de build wordt doorgegeven of mislukt. De buildstatus wordt weergegeven op de volgende tabbladen:

  • Bestanden: Geeft de status van de nieuwste build voor de geselecteerde vertakking aan.
  • Doorvoeringen: geeft de buildstatus van elke doorvoer aan (hiervoor moet de CI-trigger (continue integratie) zijn ingeschakeld voor uw builds.
  • Vertakkingen: Geeft de status van de nieuwste build voor elke vertakking aan.

Als u meerdere build-pijplijnen gebruikt voor dezelfde opslagplaats in uw project, kunt u deze optie inschakelen voor een of meer van de pijplijnen. In het geval dat deze optie is ingeschakeld voor meerdere pijplijnen, geeft de badge op de codepagina de status van de nieuwste build voor alle pijplijnen aan. Uw teamleden kunnen op de badge buildstatus klikken om de meest recente buildstatus voor elk van de build-pijplijnen weer te geven.

GitHub

Als uw bronnen zich in GitHub bevinden, publiceert deze optie de status van uw build naar GitHub met behulp van GitHub-controles of status-API's. Als uw build wordt geactiveerd vanuit een GitHub-pull-aanvraag, kunt u de status bekijken op de pagina pull-aanvragen van GitHub. Hiermee kunt u ook statusbeleid instellen in GitHub en samenvoegingen automatiseren. Als uw build wordt geactiveerd door continue integratie (CI), kunt u de buildstatus bekijken op de doorvoer of vertakking in GitHub.

Andere typen externe Git-opslagplaatsen

Als uw bron zich in een ander type externe opslagplaats bevindt, kunt u Azure Pipelines of TFS niet gebruiken om de buildstatus automatisch naar die opslagplaats te publiceren. U kunt echter een buildbadge gebruiken als een manier om de buildstatus te integreren en weer te geven binnen uw versiebeheerervaringen.

Pad naar uitchecken

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

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

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

Als u meerdere checkout stappen gebruikt en meerdere opslagplaatsen uitcheckt en de map expliciet wilt opgeven met behulp pathvan, kunt u het instellingspad vermijden dat een submap is van het pad van een andere uitcheckstap (bijvoorbeeld C:\agent\_work\1\s\repo1 en C:\agent\_work\1\s\repo1\repo2), anders wordt de submap van de uitcheckstap gewist door de reiniging van een andere opslagplaats. Houd er rekening mee dat dit geval geldig is als de schone optie waar is voor repo1)

Notitie

Het uitcheckpad kan alleen worden opgegeven voor YAML-pijplijnen. Zie Uitchecken in het YAML-schema voor meer informatie.

Submodules uitchecken

Selecteer of u bestanden wilt downloaden uit submodules. U kunt ervoor kiezen om de directe submodules of alle submodules te nesten op elke diepte van recursie. Als u LFS wilt gebruiken met submodules, moet u de opmerking over het gebruik van LFS met submodules bekijken.

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

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

  • Geverifieerde:

    • Opgenomen in hetzelfde project, GitHub-organisatie of Bitbucket Cloud-account als de Hierboven opgegeven Git-opslagplaats.

    • Toegevoegd met behulp van een URL ten opzichte van de hoofdopslagplaats. Deze zou bijvoorbeeld worden uitgecheckt: git submodule add /../../submodule.git mymodule Deze zou niet worden uitgecheckt: git submodule add https://dev.azure.com/fabrikamfiber/_git/ConsoleApp mymodule

Geverifieerde submodules

Notitie

Zorg ervoor dat u uw submodules hebt geregistreerd met HTTPS en niet met behulp van SSH.

Dezelfde referenties die door de agent worden gebruikt om de bronnen op te halen uit de hoofdopslagplaats, worden ook gebruikt om de bronnen voor submodules op te halen.

Als uw hoofdopslagplaats en submodules zich in een Git-opslagplaats van Azure-opslagplaatsen in uw Azure DevOps-project bevinden, kunt u het account selecteren dat wordt gebruikt voor toegang tot de bronnen. Selecteer op het tabblad Opties in het menu Autorisatiebereik van buildtaak een van de volgende opties:

  • Projectverzameling voor het gebruik van het serviceaccount Project Collection Build

  • Huidig project voor het gebruik van het Project Build Service-account.

Zorg ervoor dat het account dat u gebruikt, toegang heeft tot zowel de hoofdopslagplaats als de submodules.

Als uw hoofdopslagplaats en submodules zich in dezelfde GitHub-organisatie bevinden, wordt het token dat is opgeslagen in de GitHub-serviceverbinding gebruikt om toegang te krijgen tot de bronnen.

Alternatief voor het gebruik van de optie Uitchecken-submodules

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

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

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

Zorg ervoor dat u '<BASIC_AUTH_TOKEN>' vervangt door uw met Base64 gecodeerde token.

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

Notitie

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

Bestanden van LFS uitchecken

Selecteer of u bestanden wilt downloaden uit grote bestandsopslag (LFS).

Schakel in de klassieke editor het selectievakje in om deze optie in te schakelen.

Voeg in een YAML-build een uitcheckstap toe met lfs de volgende instellingen true:

steps:
- checkout: self
  lfs: true

Als u TFS gebruikt of Als u Azure Pipelines gebruikt met een zelf-hostende agent, moet u de agent installeren git-lfs om deze optie te laten werken. Als uw gehoste agents Windows gebruiken, kunt u overwegen de System.PreferGitFromPath variabele te gebruiken om ervoor te zorgen dat pijplijnen de versies van git en git-lfs gebruiken die u op de computer hebt geïnstalleerd. Zie voor meer informatie welke versie van Git mijn agent wordt uitgevoerd?

Git LFS gebruiken met submodules

Als een submodule LFS-bestanden bevat, moet Git LFS worden geconfigureerd voordat u submodules uitcheckt. De door Microsoft gehoste macOS- en Linux-agents worden op deze manier vooraf geconfigureerd. Windows-agents en zelf-hostende macOS-/Linux-agents zijn mogelijk niet.

Als tijdelijke oplossing kunt u, als u YAML gebruikt, de volgende stap toevoegen voordat checkoutu:

steps:
- script: |
    git config --global --add filter.lfs.required true
    git config --global --add filter.lfs.smudge "git-lfs smudge -- %%f"
    git config --global --add filter.lfs.process "git-lfs filter-process"
    git config --global --add filter.lfs.clean "git-lfs clean -- %%f"
  displayName: Configure LFS for use with submodules
- checkout: self
  lfs: true
  submodules: true
# ... rest of steps ...

Een tweede opslagplaats klonen

Uw pijplijn is standaard gekoppeld aan één opslagplaats van Azure-opslagplaatsen of een externe provider. Dit is de opslagplaats die builds kan activeren op doorvoeringen en pull-aanvragen.

Mogelijk wilt u bronnen uit een tweede opslagplaats in uw pijplijn opnemen. U kunt dit doen door een script te schrijven.

git clone https://github.com/Microsoft/TypeScript.git

Als de opslagplaats niet openbaar is, moet u verificatie doorgeven aan de Git-opdracht.

Azure-opslagplaatsen

Uw pijplijn heeft al toegang tot andere opslagplaatsen in het project en u kunt deze klonen in uw pijplijn met behulp van een scriptopdracht, zoals wordt weergegeven in het volgende voorbeeld.

- script: | 
    git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" https://organization@dev.azure.com/project/FabrikamFiber/_git/reponame

U kunt meerdere opslagplaatsen in hetzelfde project klonen als uw pijplijn met behulp van het uitchecken van meerdere opslagplaatsen.

Als u een opslagplaats wilt klonen van een ander project dat niet openbaar is, moet u zich verifiëren als een gebruiker die toegang heeft tot dat project.

Notitie

Gebruik een geheime variabele om referenties veilig op te slaan.

Geheime variabelen worden niet automatisch beschikbaar gesteld voor scripts als omgevingsvariabelen. Zie Geheime variabelen over het toewijzen ervan.

Voor Azure-opslagplaatsen kunt u een persoonlijk toegangstoken gebruiken met de machtiging Code (Lezen). Verzend dit als het wachtwoordveld in een autorisatieheader Basis zonder gebruikersnaam. (Met andere woorden, base64-codeer de waarde van :<PAT>, inclusief de dubbele punt.)

AUTH=$(echo -n ":$REPO_PAT" | openssl base64 | tr -d '\n')
git -c http.<repo URL>.extraheader="AUTHORIZATION: basic $AUTH" clone <repo URL> --no-checkout --branch master

Bronnen niet synchroniseren

Niet-implementatietaken halen automatisch bronnen op. Gebruik deze optie als u dat gedrag wilt overslaan. Deze optie kan handig zijn in gevallen waarin u het volgende wilt doen:

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

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

Als u het downloaden van bronnen wilt uitschakelen:

  • Azure Pipelines, TFS 2018 en hoger: klik op Geavanceerde instellingen en selecteer Bronnen niet synchroniseren.

Notitie

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

Ondiep ophalen

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

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

Notitie

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

Nadat u het selectievakje hebt ingeschakeld om deze optie in te schakelen, geeft u in het vak Diepte het aantal doorvoeringen op.

Tip

De Agent.Source.Git.ShallowFetchDepth hieronder genoemde variabele werkt ook en overschrijft de besturingselementen van het selectievakje. Op deze manier kunt u de instelling wijzigen wanneer u de build in de wachtrij zet.

De voorkeur geven aan Git vanuit het pad

De Windows-agent gebruikt standaard de versie van Git die is gebundeld met de agentsoftware. Microsoft raadt aan om de versie van Git te gebruiken die is gebundeld met de agent, maar u hebt verschillende opties om dit standaardgedrag te overschrijven en de versie van Git te gebruiken die de agentmachine in het pad heeft geïnstalleerd.

Als u de versie van Git wilt zien die door een pijplijn wordt gebruikt, kunt u de logboeken voor een checkout stap in uw pijplijn bekijken, zoals wordt weergegeven in het volgende voorbeeld.

Syncing repository: PathFilter (Git)
Prepending Path environment variable with directory containing 'git.exe'.
git version
git version 2.26.2.windows.1

Deze instelling geldt altijd voor niet-Windows-agents.

Triggeropties voor andere Git

Wanneer er een andere/externe Git-opslagplaats is opgegeven, is voor CI-builds vereist dat de opslagplaats toegankelijk is vanaf internet. Als de opslagplaats zich achter een firewall of proxy bevindt, werken alleen geplande en handmatige builds.

Veelgestelde vragen

Welke protocollen kunnen de buildagent gebruiken met Git?

De agent ondersteunt HTTPS.

De agent biedt nog geen ondersteuning voor SSH. Zie Build toestaan om SSH-verificatie te gebruiken tijdens het uitchecken van Git-submodules.

Ik gebruik TFS on-premises en ik zie sommige van deze functies niet. Waarom niet?

Sommige van deze functies zijn alleen beschikbaar in Azure Pipelines en zijn nog niet on-premises beschikbaar. Sommige functies zijn on-premises beschikbaar als u een upgrade hebt uitgevoerd naar de nieuwste versie van TFS.