A Git-adattárak folyamatbeállításai

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019

Egy Git-adattárat használó folyamat szerkesztése közben – egy Azure DevOps-projektben, a GitHubon, a GitHub Enterprise Serveren, a Bitbucket Cloudban vagy egy másik Git-adattárban – az alábbi lehetőségek közül választhat.

Szolgáltatás	Azure Pipelines	Azure DevOps Server 2019 és újabb verziók	TFS 2018
Ág	Igen	Igen	Igen
Clean	Igen	Igen	Igen
Források címkézése vagy címkézése	Projekt; Csak klasszikus	Csapatprojekt	Csapatprojekt
Jelentés összeállítási állapota	Igen	Igen	Igen
Almodulok kivétele	Igen	Igen	Igen
Fájlok kivétele az LFS-ből	Igen	Igen	Igen
Második adattár klónozása	Igen	Igen	Igen
Források szinkronizálásának mellőzve	Igen	Igen	Igen
Sekély lekérés	Igen	Igen	Igen

Feljegyzés

Kattintson a Speciális beállítások elemre a Források lekérése feladatban a fenti beállítások megtekintéséhez.

Ág

Ez az az ág, amelyet a build manuális várólistára helyezésekor alapértelmezettként szeretne használni. Ha ütemezett eseményindítót állít be a buildhez, ez az az ág, ahonnan a build a legújabb forrásokat fogja kapni. Az alapértelmezett ágnak nincs köze a folyamatos integráció (CI) által aktivált buildhez. Ez általában megegyezik az adattár alapértelmezett ágával (például "master").

A helyi adattár tisztítása az ügynökön

A saját üzemeltetésű ügynök munkakönyvtárának tisztításának különböző formáit végezheti el a build futtatása előtt.

Általánosságban elmondható, hogy a saját üzemeltetésű ügynökök gyorsabb teljesítménye érdekében ne tisztítsa meg az adattárat. Ebben az esetben a legjobb teljesítmény érdekében győződjön meg arról, hogy növekményesen is épít, ha letiltja a buildeléshez használt tevékenység vagy eszköz tiszta beállítását.

Ha törölnie kell az adattárat (például az előző buildből származó reziduális fájlok által okozott problémák elkerülése érdekében), a lehetőségek alább találhatók.

Feljegyzés

A tisztítás nem hatékony, ha Microsoft által üzemeltetett ügynököt használ, mert minden alkalommal új ügynököt kap. Ha saját üzemeltetésű ügynököket használ, attól függően, hogy az ügynökkészletek hogyan vannak konfigurálva, új ügynököt kaphat a későbbi folyamatfuttatásokhoz (vagy ugyanabban a folyamatban lévő szakaszokhoz vagy feladatokhoz), így a tisztítás nem garantálja, hogy a későbbi futtatások, feladatok vagy szakaszok hozzáférhetnek a korábbi futtatások, feladatok vagy szakaszok kimeneteihez.

YAML

Azure Pipelines, Azure DevOps Server 2019 és újabb

A YAML-folyamatokhoz számos különböző tiszta beállítás érhető el.

• A checkout lépésnek van egy clean lehetősége. Ha be van trueállítva, a folyamat az adattár beolvasása előtt fut execute git clean -ffdx && git reset --hard HEAD . További információt a Kivétel című témakörben talál.
• A workspace beállítás job több tiszta beállítással rendelkezik (kimenetek, erőforrások, mind). További információ: Munkaterület.
• A folyamatbeállítások felhasználói felülete tiszta beállítással rendelkezik, amely igaz értékre állítása egyenértékű a folyamat minden checkout lépésének megadásávalclean: true. A Tiszta beállítás konfigurálása:

  1. Szerkessze a folyamatot, válassza a ..., majd az Eseményindítók lehetőséget.

     

  2. Válassza ki a YAML-t, kérje le a forrásokat, és konfigurálja a kívánt Tiszta beállítást. Az alapértelmezett érték igaz.

     

A folyamat manuális futtatásakor a tiszta beállítások felülbírálásához használhat futtatókörnyezeti paramétereket. Az alábbi példában egy futtatókörnyezeti paraméter használatával konfigurálja a kivétel tiszta beállítását.

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

Alapértelmezés szerint be van állítva, clean de felül lehet bírálni a folyamat manuális futtatásakor a futásidejű paraméterhez hozzáadott Kivétel tiszta jelölőnégyzet jelölésének törlésével.true

Klasszikus

Azure Pipelines, TFS 2018, TFS 2017.2, TFS 2017.3

Válasszon a következő lehetőségek közül:

• Források: A buildelési folyamat visszavonja a módosításokat a fájlban $(Build.SourcesDirectory). Pontosabban a következő Git-parancsokat hajtja végre a rendszer a forrás lekérése előtt.

  git clean -ffdx
  git reset --hard HEAD
  

• Források és kimeneti könyvtár: Ugyanaz a művelet, mint a fenti Források lehetőség, plusz: Törli és újra létrehozza $(Build.BinariesDirectory). Vegye figyelembe, hogy az $(Build.ArtifactStagingDirectory) és $(Common.TestResultsDirectory) mindig törlődnek és újra létrejönnek minden build előtt, függetlenül ezektől a beállításoktól.

• Forráskönyvtár: Törli és újra létrehozza $(Build.SourcesDirectory). Ez egy új, helyi Git-adattár inicializálását eredményezi minden buildhez.

• Minden buildkönyvtár: Törli és újra létrehozza $(Agent.BuildDirectory). Ez egy új, helyi Git-adattár inicializálását eredményezi minden buildhez.

Címkeforrások

Érdemes lehet címkézni a forráskódfájlokat, hogy a csapat könnyen azonosíthassa az egyes fájlok melyik verzióját tartalmazza a befejezett buildben. Azt is megadhatja, hogy a forráskódot az összes buildhez fel kell-e címkézni, vagy csak a sikeres buildekhez.

Feljegyzés

Ezt a funkciót csak akkor használhatja, ha a build forrásadattára Egy GitHub-adattár, vagy egy Git- vagy TFVC-adattár a projektből.

Címkeformátumban használhat felhasználó által definiált és előre definiált változókat, amelyek hatóköre "Mind". Például:

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

Az első négy változó előre definiálva van. My.Variablea változók lapon definiálhatja.

A buildelési folyamat egy Git-címkével jelöli meg a forrásokat.

Egyes buildváltozók olyan értéket eredményezhetnek, amely nem érvényes címke. Például olyan változók, mint például $(Build.RequestedFor) a szabad terület, és $(Build.DefinitionName) tartalmazhatnak szóközt. Ha az érték üres területet tartalmaz, a címke nem jön létre.

Miután a buildelési folyamat címkézte a forrásokat, a rendszer automatikusan hozzáad egy Git-ref-et refs/tags/{tag} tartalmazó összetevőt a befejezett buildhez. Ez további nyomon követhetőséget biztosít a csapatnak, és felhasználóbarátabb módot kínál a buildről a létrehozott kódra való navigáláshoz. A címke buildösszetevőnek minősül, mivel a build hozza létre. Ha a buildet manuálisan vagy megőrzési szabályzattal törlik, a címke is törlődik.

Jelentéskészítés állapota (Azure Pipelines, TFS 2018 és újabb)

Lehetősége van arra, hogy a csapatának megtekintse a távoli forrásadattár buildelési állapotát.

Ha a források egy Azure Repos Git-adattárban találhatók a projektben, akkor ez a beállítás egy jelvényt jelenít meg a Kód lapon, amely jelzi, hogy a build halad-e vagy nem működik. A build állapota a következő lapokon jelenik meg:

• Fájlok: A kijelölt ág legújabb buildjének állapotát jelzi.
• Véglegesítések: Az egyes véglegesítések buildállapotát jelzi (ehhez engedélyezni kell a folyamatos integrációs (CI) eseményindítót a buildekhez).
• Ágak: Az egyes ágak legújabb buildjének állapotát jelzi.

Ha több buildfolyamatot is használ ugyanahhoz az adattárhoz a projektben, akkor engedélyezheti ezt a beállítást egy vagy több folyamat esetében. Abban az esetben, ha ez a beállítás több folyamaton is engedélyezve van, a Kód lapon lévő jelvény az összes folyamat legújabb buildjének állapotát jelzi. A csapattagok a buildállapot-jelvényre kattintva megtekinthetik az egyes buildelési folyamatok legújabb buildállapotát.

GitHub

Ha a források a GitHubon találhatók, akkor ez a beállítás közzéteszi a build állapotát a GitHubon a GitHub-ellenőrzések vagy állapot API-k használatával. Ha a build egy GitHub-lekéréses kérelemből indul ki, az állapotot a GitHub lekéréses kérelmek lapján tekintheti meg. Ez azt is lehetővé teszi, hogy állapotszabályzatokat állítson be a GitHubon, és automatizálja az egyesítéseket. Ha a buildet folyamatos integráció (CI) váltja ki, akkor megtekintheti a build állapotát a véglegesítésen vagy ágon a GitHubon.

A Git távoli adattárainak egyéb típusai

Ha a forrás bármilyen más típusú távoli adattárban található, akkor az Azure Pipelines vagy a TFS nem használható a build állapotának automatikus közzétételére az adott adattárban. A buildjelvény használatával azonban integrálhatja és megjelenítheti a build állapotát a verziókövetési szolgáltatásokban.

Kivétel elérési útja

Ha egyetlen adattárat vesz ki, a forráskód alapértelmezés szerint ki lesz véve egy úgynevezett skönyvtárba. YAML-folyamatok esetén ezt checkout módosíthatja egy path. A megadott elérési út a következőhöz viszonyítva $(Agent.BuildDirectory)van: . Ha például a pénztár elérési útja értéke és $(Agent.BuildDirectory) az mycustompathC:\agent\_work\1, akkor a forráskód ki lesz véve a programbólC:\agent\_work\1\mycustompath.

Ha több checkout lépést használ, és több adattárat is kivesz, és nem explicit módon adja meg a mappát a használatával path, az egyes adattárak az adattárról elnevezett almappába s kerülnek. Ha például két elnevezett tools adattárat vesz fel, és codea forráskódot a rendszer kiveszi a programbólC:\agent\_work\1\s\tools.C:\agent\_work\1\s\code

Vegye figyelembe, hogy a pénztár elérési útjának értéke nem állítható be úgy, hogy a fenti $(Agent.BuildDirectory)könyvtárszintek egyikére se lépjen fel, ezért path\..\anotherpath érvényes kivételi elérési utat eredményez (azaz C:\agent\_work\1\anotherpath), de egy ilyen ..\invalidpath érték nem lesz (azaz C:\agent\_work\invalidpath).

Ha több checkout lépést használ, és több tárházat is kivesz, és explicit módon szeretné megadni a mappát a használatával path, akkor érdemes elkerülni a másik kivételi lépés elérési útjának almappáját (vagyis C:\agent\_work\1\s\repo1C:\agent\_work\1\s\repo1\repo2azt), ellenkező esetben a kivételi lépés almappáját egy másik tárház tisztítása törli. Vegye figyelembe, hogy ez az eset érvényes, ha a tiszta beállítás igaz a következőre repo1: )

Feljegyzés

A kivételi útvonal csak YAML-folyamatokhoz adható meg. További információ: Kivétel a YAML-sémában.

Almodulok kivétele

Válassza ki, ha almodulokból szeretne fájlokat letölteni. Választhatja, hogy az azonnali almodulokat vagy az összes almodult bármilyen rekurziós mélységbe ágyazva kapja meg. Ha az LFS-t almodulokkal szeretné használni, mindenképpen olvassa el az LFS almodulokkal való használatáról szóló megjegyzést.

Feljegyzés

További információ a YAML-szintaxisról az almodulok kivételéhez: Kivétel a YAML-sémában.

A buildelési folyamat mindaddig ellenőrzi a Git-almodulokat, amíg azok a következők:

• Hitelesítés nélküli: Nyilvános, hitelesítés nélküli adattár, amely nem rendelkezik a klónozáshoz vagy lekéréshez szükséges hitelesítő adatokkal.

• Hitelesített:

  • Ugyanabban a projektben, a GitHub-szervezetben vagy a Bitbucket Cloud-fiókban található, mint a fent megadott Git-adattár.

  • Hozzáadva a fő adattárhoz viszonyított URL-cím használatával. Ezt például kivenné a rendszer: git submodule add /../../submodule.git mymodule Ezt nem venné ki a rendszer: git submodule add https://dev.azure.com/fabrikamfiber/_git/ConsoleApp mymodule

Hitelesített almodulok

Feljegyzés

Győződjön meg arról, hogy az almodulokat HTTPS használatával regisztrálta, és nem SSH-t.

Ugyanezeket a hitelesítő adatokat használja az ügynök a fő adattár forrásainak lekéréséhez is.

Ha a fő adattár és almodulok az Azure DevOps-projekt egyik Azure Repos Git-adattárában találhatók, kiválaszthatja a források eléréséhez használt fiókot. A Beállítások lap Build feladatengedélyezési hatókör menüjében válassza a következő lehetőségeket:

• Projektgyűjtemény a Project Collection Build szolgáltatásfiók használatához

• Aktuális projekt a Project Build Service-fiók használatához.

Győződjön meg arról, hogy bármelyik fiókot is használja, hozzáféréssel rendelkezik mind a fő adattárhoz, mind az almodulokhoz.

Ha a fő adattár és almodulok ugyanabban a GitHub-szervezetben találhatók, akkor a Rendszer a GitHub szolgáltatáskapcsolatban tárolt jogkivonatot használja a források eléréséhez.

Alternatív megoldás a Kivétel almodulok lehetőség használatára

Bizonyos esetekben nem használhatja a Kivétel almodulok lehetőséget. Előfordulhat, hogy az almodulok eléréséhez más hitelesítő adatokra van szükség. Ez például akkor fordulhat elő, ha a fő adattár és az almodul-adattárak nincsenek ugyanabban az Azure DevOps-szervezetben vagy Git-szolgáltatásban tárolva.

Ha nem tudja használni a Kivétel almodulok lehetőséget, akkor ehelyett használhat egyéni szkriptlépést az almodulok beolvasásához. Először szerezze be a személyes hozzáférési jogkivonatot (PAT) és előtaggal pat:. Ezután a base64 kódolja ezt az előtagú sztringet egy alapszintű hitelesítési jogkivonat létrehozásához. Végül adja hozzá ezt a szkriptet a folyamathoz:

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

Mindenképpen cserélje le a "<BASIC_AUTH_TOKEN>" kifejezést a Base64-kódolt jogkivonatra.

Használjon titkos változót a projektben vagy a buildelési folyamatban a létrehozott alapszintű hitelesítési jogkivonat tárolásához. Ezzel a változóval töltse ki a titkos kódot a fenti Git-parancsban.

Feljegyzés

K: Miért nem tudok Git hitelesítőadat-kezelőt használni az ügynökön?Válasz: Az almodul hitelesítő adatainak tárolása a privát buildügynökön telepített Git hitelesítőadat-kezelőben általában nem hatékony, mivel a hitelesítőadat-kezelő megkérheti, hogy adja meg újra a hitelesítő adatokat az almodul frissítésekor. Ez nem kívánatos az automatizált buildek során, ha a felhasználói interakció nem lehetséges.

Fájlok kivétele az LFS-ből

Válassza ki, ha nagy fájltárolóból (LFS) szeretne fájlokat letölteni.

A klasszikus szerkesztőben jelölje be a jelölőnégyzetet a beállítás engedélyezéséhez.

YAML-buildben adjon hozzá egy kivételi lépést a következő beállítással lfstrue:

steps:
- checkout: self
  lfs: true

Ha TFS-t használ, vagy ha az Azure Pipelinest egy saját üzemeltetésű ügynökkel használja, akkor telepítenie kell git-lfs az ügynököt a beállítás működéséhez. Ha az üzemeltetett ügynökök Windowst használnak, fontolja meg a System.PreferGitFromPath változó használatát annak biztosítására, hogy a folyamatok a számítógépre telepített Git- és Git-lfs-verziókat használják. További információ: Milyen git-verziót futtat az ügynököm?

Git LFS használata almodulokkal

Ha egy almodul LFS-fájlokat tartalmaz, a Git LFS-t konfigurálni kell az almodulok kivétele előtt. A Microsoft által üzemeltetett macOS- és Linux-ügynökök így előre konfigurálva lesznek. Előfordulhat, hogy a Windows-ügynökök és a saját üzemeltetésű macOS/Linux-ügynökök nem.

Áthidaló megoldásként, ha YAML-et használ, a következő lépést veheti fel a checkoutkövetkező elé:

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

Második adattár klónozása

Alapértelmezés szerint a folyamat egy Azure-adattárhoz vagy egy külső szolgáltatóhoz van társítva. Ez az adattár képes buildeket aktiválni véglegesítésekre és lekéréses kérelmekre.

Érdemes lehet egy második adattár forrásait is belefoglalni a folyamatba. Ezt szkript írásával teheti meg.

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

Ha az adattár nem nyilvános, át kell adnia a hitelesítést a Git-parancsnak.

Azure Repos

Több adattárat is klónozhat ugyanabban a projektben, mint a folyamat, több adattárbeli kivétel használatával.

Ha egy olyan projektből kell klónoznia egy adattárat, amely nem nyilvános, hitelesítést kell végeznie olyan felhasználóként, aki hozzáféréssel rendelkezik a projekthez.

Feljegyzés

Titkos változó használatával biztonságosan tárolhatja a hitelesítő adatokat.

A titkos változók nem lesznek automatikusan elérhetővé a szkriptek számára környezeti változóként. A titkos változók beképezési módjával kapcsolatban lásd: Titkos kódváltozók.

Az Azure Repos esetében használhat egy személyes hozzáférési jogkivonatot a Kód (Olvasás) engedéllyel. Küldje el ezt jelszómezőként egy "Alapszintű" engedélyezési fejlécben felhasználónév nélkül. (Más szóval a base64 kódolja a kettőspont értékét :<PAT>is.)

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

Források szinkronizálásának mellőzve

A nem üzembe helyezési feladatok automatikusan beolvasják a forrásokat. Ezt a beállítást akkor használja, ha kihagyja ezt a viselkedést. Ez a beállítás a következő esetekben lehet hasznos:

• A Git inicializálása, konfigurálása és beolvasása a saját egyéni beállításaival.

• A buildelési folyamatokkal egyszerűen futtathat automatizálást (például néhány szkriptet), amelyek nem függnek a verziókövetésben lévő kódtól.

Ha le szeretné tiltani a források letöltését:

• Azure Pipelines, TFS 2018 és újabb: Kattintson a Speciális beállítások elemre, majd válassza a Források szinkronizálásának mellőzése lehetőséget.

Feljegyzés

Ha ezt a beállítást használja, az ügynök kihagyja az adattárat megtisztító Git-parancsok futtatását is.

Sekély lekérés

Válassza ki, hogy szeretné-e korlátozni a korábbi letöltési időkorlátot. Ez gyakorlatilag a következőt git fetch --depth=neredményezi: . Ha az adattár nagy, ez a beállítás hatékonyabbá teheti a buildelési folyamatot. Az adattár nagy méretű lehet, ha már régóta használatban van, és jelentős előzményei vannak. Nagy méretű is lehet, ha nagy fájlokat adott hozzá, majd később törölt.

Ezekben az esetekben ez a beállítás segíthet a hálózati és tárolási erőforrások megőrzésében. Időt is megtakaríthat. Azért nem mindig takarít meg időt, mert bizonyos helyzetekben előfordulhat, hogy a kiszolgálónak időt kell töltenie a letöltéshez szükséges véglegesítések kiszámításával a megadott mélységben.

Feljegyzés

A build várólistára helyezésekor a buildelendő ág véglegesítési azonosítóra lesz feloldva. Ezután az ügynök lekéri az ágat, és ellenőrzi a kívánt véglegesítést. Az ág véglegesítési azonosítóra való feloldása és a kivétel végrehajtása között van egy kis ablak. Ha az ág gyorsan frissül, és egy nagyon kis értéket állít be a sekély lekéréshez, előfordulhat, hogy a véglegesítés nem létezik, amikor az ügynök megpróbálja kivenni. Ha ez történik, növelje a beolvasási mélység beállítását.

Miután bejelölte a jelölőnégyzetet a beállítás engedélyezéséhez, a Mélység mezőben adja meg a véglegesítések számát.

Tipp.

Az Agent.Source.Git.ShallowFetchDepth alábbi változó szintén működik, és felülbírálja a jelölőnégyzet vezérlőit. Így módosíthatja a beállítást, amikor várólistára állítja a buildet.

A Git előnyben részesítve az elérési útról

A Windows-ügynök alapértelmezés szerint az ügynökszoftverhez csomagolt Git-verziót használja. A Microsoft azt javasolja, hogy használja az ügynökkel együtt csomagolt Git-verziót, de számos lehetősége van az alapértelmezett viselkedés felülbírálására, és a Git azon verziójának használatára, amelyet az ügynökgép telepített az útvonalon.

• Állítson be egy folyamatváltozót, amely a true folyamatokban szerepelSystem.PreferGitFromPath.
• A saját üzemeltetésű ügynökökben létrehozhat egy .env nevű fájlt az ügynök gyökérkönyvtárában, és hozzáadhat egy System.PreferGitFromPath=true sort a fájlhoz. További információ: Hogyan különböző környezeti változókat állíthat be az egyes ügynökökhöz?

A folyamat által használt Git-verzió megtekintéséhez megtekintheti a folyamat egy checkout lépésének naplóit, ahogyan az az alábbi példában is látható.

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

Ez a beállítás mindig igaz a nem Windows-ügynökökre.

Egyéb Git-eseményindítók beállításai

Ha más/külső Git-adattár van megadva, a CI-buildek megkövetelik, hogy az adattár elérhető legyen az internetről. Ha az adattár tűzfal vagy proxy mögött található, akkor csak az ütemezett és a manuális buildek fognak működni.

GYIK

Milyen protokollokat használhat a buildügynök a Gittel?

Az ügynök támogatja a HTTPS-t.

Az ügynök még nem támogatja az SSH-t. Lásd: Az SSH-hitelesítés használatának engedélyezése a Git-almodulok ellenőrzésekor.