Azure Repos Git- vagy TFS Git-adattárak létrehozása

  • Cikk

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

Az Azure Pipelines automatikusan létrehozhat és érvényesíthet minden lekéréses kérelmet, és véglegesítheti az Azure Repos Git-adattárat.

Hozzon létre egy adattárat

Új folyamatot úgy hozhat létre, hogy először kiválaszt egy adattárat, majd egy YAML-fájlt az adattárban. Az adattár, amelyben a YAML-fájl található, adattárnak nevezzük self . Alapértelmezés szerint ez az az adattár, amelyet a folyamat létrehoz.

Később konfigurálhatja a folyamatot egy másik adattár vagy több adattár megtekintésére. Ennek módjáról további információt a több-adattárak kivételét ismertető cikkben talál.

Az Azure Pipelinesnak hozzáférést kell biztosítani az adattárakhoz a buildek aktiválásához és a kód lekéréséhez a buildek során. Általában egy folyamat hozzáféréssel rendelkezik ugyanabban a projektben lévő adattárakhoz. Ha azonban egy másik projekt adattáraihoz szeretne hozzáférni, frissítenie kell a feladat-hozzáférési jogkivonatokhoz megadott engedélyeket.

CI-eseményindítók

A folyamatos integrációs (CI) eseményindítók hatására a folyamat akkor fut, amikor frissítést küld a megadott ágakba, vagy leküldi a megadott címkéket.

A YAML-folyamatok alapértelmezés szerint egy CI-eseményindítóval vannak konfigurálva az összes ágon, kivéve, ha az Azure DevOps sprint 227-ben bevezetett Implicit YAML CI-eseményindító beállítása engedélyezve van. A hallgatólagos YAML CI-eseményindító letiltása beállítás a szervezet szintjén vagy a projekt szintjén konfigurálható. Ha engedélyezve van a vélelmezett YAML CI-eseményindító beállítása, a YAML-folyamatok CI-eseményindítói nem lesznek engedélyezve, ha a YAML-folyamatnak nincs trigger szakasza. Alapértelmezés szerint a vélelmezett YAML CI-eseményindító letiltása nincs engedélyezve.

Ágak

Egyszerű szintaxissal szabályozhatja, hogy mely ágak kapják meg a CI-eseményindítókat:

trigger:
- main
- releases/*

Megadhatja az ág teljes nevét (például main) vagy helyettesítő karaktert (például releases/*). A helyettesítő karakterek szintaxisával kapcsolatos információkért tekintse meg a helyettesítő karaktereket .

Feljegyzés

Az eseményindítókban nem használhat változókat , mivel a változók kiértékelése futásidőben történik (az eseményindító elindítása után).

Feljegyzés

Ha sablonokkal hoz létre YAML-fájlokat, akkor csak a folyamat fő YAML-fájljában adhat meg eseményindítókat. A sablonfájlokban nem adhatók meg eseményindítók.

Összetettebb, vagy batchazt használó exclude eseményindítók esetén a teljes szintaxist kell használnia az alábbi példában látható módon.

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

A fenti példában a folyamat akkor aktiválódik, ha a rendszer egy módosítást küld le a kiadási ágba main vagy bármely kiadási ágba. Ez azonban nem aktiválódik, ha módosítást végez egy kiadási ágon, amely a következővel oldkezdődik: .

Ha záradék nélküli záradékot excludeinclude ad meg, az egyenértékű a include záradékban megadottakkal*.

A listákban szereplő branches ágnevek megadása mellett címkék alapján is konfigurálhatja az eseményindítókat az alábbi formátum használatával:

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

Ha nem adott meg eseményindítókat, és az implicit YAML CI-eseményindító letiltása beállítás nincs engedélyezve, az alapértelmezett beállítás a következő, mintha a következőt írta volna:

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

Fontos

Eseményindító megadásakor az alapértelmezett implicit eseményindító helyébe lép, és csak a kifejezetten belefoglalni kívánt ágakra történő leküldések aktiválják a folyamatot. A rendszer először feldolgozta a benne szereplő elemeket, majd eltávolítja a kizárásokat a listából.

CI-futtatások kötegelése

Ha sok csapattag gyakran tölt fel módosításokat, érdemes lehet csökkenteni a kezdési futtatások számát. Ha azt állítja be batch , hogy trueamikor egy folyamat fut, a rendszer megvárja a futtatás befejezését, majd elindít egy újabb futtatási elemet az összes olyan módosítással, amely még nem készült el.

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

Feljegyzés

batch nem támogatott az adattárbeli erőforrás-eseményindítókban.

A példa tisztázásához tegyük fel, hogy a fenti folyamat futtatását main egy leküldés A okozta. Amíg a folyamat fut, további leküldések BC következnek be az adattárba. Ezek a frissítések nem indítják el azonnal az új független futtatásokat. Az első futtatás befejezése után azonban az összes leküldés addig történik, amíg az adott időpontot össze nem köti a rendszer, és új futtatás indul el.

Feljegyzés

Ha a folyamat több feladattal és fázissal rendelkezik, akkor az első futtatásnak továbbra is terminálállapotba kell kerülnie, ha befejezi vagy kihagyja az összes feladatot és szakaszt, mielőtt a második futtatás elindulhat. Ezért körültekintően kell eljárnia, ha ezt a funkciót több fázist vagy jóváhagyást tartalmazó folyamatban használja. Ha ilyen esetekben szeretné a buildeket kötegelni, javasoljuk, hogy a CI/CD-folyamatot két folyamatra ossza fel– egyet a buildeléshez (kötegeléssel), egyet pedig az üzembe helyezéshez.

Elérési utak

Megadhatja a belefoglalni vagy kizárni kívánt fájlelérési utakat.

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

Elérési utak megadásakor explicit módon meg kell adnia azokat az ágakat, amelyeken aktiválni kell az Azure DevOps Server 2019.1 vagy újabb verziójának használatakor. Nem indíthat csak elérésiút-szűrővel rendelkező folyamatot; az elágaztatási szűrővel is rendelkeznie kell, és az elérési út szűrőjének megfelelő módosított fájloknak az ágszűrőnek megfelelő ágból kell származnia. Ha az Azure DevOps Server 2020 vagy újabb verziót használja, kihagyhatja branches az összes ágra való szűrést az elérésiút-szűrővel együtt.

Az elérésiút-szűrők támogatják a helyettesítő kártyákat. Például az összes egyező src/app/**/myapp*elérési utat befoglalhatja. Használhat helyettesítő karaktereket (**vagy *?) elérésiút-szűrők megadásakor).

  • Az elérési utak mindig az adattár gyökeréhez viszonyítva vannak megadva.
  • Ha nem állít be elérésiút-szűrőket, akkor az adattár gyökérmappája alapértelmezés szerint implicit módon szerepel.
  • Ha kizár egy elérési utat, azt csak akkor tudja belefoglalni, ha egy mélyebb mappába sorolja. Ha például kizárja a /tools elemet , akkor a /tools/trigger-runs-on-these
  • Az elérésiút-szűrők sorrendje nem számít.
  • A Git elérési útjai megkülönböztetik a kis- és nagybetűket. Mindenképpen ugyanazt az esetet használja, mint a valódi mappákat.
  • Az elérési utakban nem használhat változókat , mivel a változók kiértékelése futásidőben történik (az eseményindító elindítása után).

Címkék

Az előző szakaszban tárgyalt listákban szereplő branches címkék megadása mellett közvetlenül megadhatja a belefoglalni vagy kizárni kívánt címkéket:

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

Ha nem ad meg címke-eseményindítókat, akkor alapértelmezés szerint a címkék nem aktiválják a folyamatokat.

Fontos

Ha elágazási szűrőkkel együtt ad meg címkéket, az eseményindító akkor aktiválódik, ha az ágszűrő teljesül, vagy a címkeszűrő teljesül. Ha például egy leküldéses címke megfelel az ágszűrőnek, a folyamat akkor is aktiválódik, ha a címkét kizárja a címkeszűrő, mert a leküldés megfelel az ágszűrőnek.

A CI-ről való lemondás

A CI-eseményindító letiltása

A CI-eseményindítókat teljes egészében kikapcsolhatja a trigger: nonebeállítás megadásával.

# A pipeline with no CI trigger
trigger: none

Fontos

Amikor egy ágra küld egy módosítást, a rendszer kiértékeli az ág YAML-fájljának kiértékelését annak megállapítására, hogy el kell-e indítani a CI-futtatásokat.

Ci kihagyása egyéni leküldésekhez

Azt is megmondhatja az Azure Pipelinesnak, hogy hagyja ki egy olyan folyamat futtatását, amelyet a leküldés általában aktivál. Csak vegye fel ***NO_CI*** a leküldés részét képező véglegesítések üzenetébe, és az Azure Pipelines kihagyja a CI futtatását ehhez a leküldéshez.

Azt is megmondhatja az Azure Pipelinesnak, hogy hagyja ki egy olyan folyamat futtatását, amelyet a leküldés általában aktivál. Csak adja meg [skip ci] a leküldés részét képező véglegesítések üzenetét vagy leírását, és az Azure Pipelines kihagyja a CI futtatását ehhez a leküldéshez. Az alábbi változatok bármelyikét is használhatja.

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

Az eseményindító típusának használata feltételek között

Gyakran előfordul, hogy a folyamat különböző lépéseit, feladatait vagy fázisait futtatja attól függően, hogy milyen típusú eseményindító indította el a futtatást. Ezt a rendszerváltozóval Build.Reasonteheti meg. Például adja hozzá a következő feltételt a lépéshez, feladathoz vagy szakaszhoz, hogy kizárja azt a pr-ellenőrzésből.

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

Eseményindítók viselkedése új ágak létrehozásakor

Gyakori, hogy ugyanazon adattárhoz több folyamatot is konfigurál. Előfordulhat például, hogy van egy folyamat az alkalmazás dokumentációjának elkészítéséhez, egy másik pedig a forráskód létrehozásához. A CI-triggereket a megfelelő ágszűrőkkel és elérésiút-szűrőkkel konfigurálhatja az egyes folyamatokban. Előfordulhat például, hogy egy folyamat aktiválódik, amikor egy frissítést küld a docs mappába, a másikat pedig az alkalmazás kódjába való frissítéskor aktiválja. Ezekben az esetekben meg kell értenie, hogyan aktiválódnak a folyamatok egy új ág létrehozásakor.

Az alábbi viselkedés történik, amikor egy új ágat küld le (amely megfelel az ágszűrőknek) az adattárba:

  • Ha a folyamat elérésiút-szűrőkkel rendelkezik, az csak akkor aktiválódik, ha az új ág olyan fájlokat módosít, amelyek megfelelnek az elérésiút-szűrőnek.
  • Ha a folyamat nem rendelkezik elérésiút-szűrőkkel, akkor is aktiválódik, ha nincs változás az új ágban.

Helyettesítő karakterek

Ág, címke vagy elérési út megadásakor pontos nevet vagy helyettesítő karaktert használhat. A helyettesítő karakterek mintái lehetővé teszik * , hogy nullával vagy több karakterrel egyezzenek, és ? egyetlen karakterrel egyezzenek.

  • Ha egy YAML-folyamatban indítja el a mintát * , a mintát idézőjelekbe kell burkolnia, például "*-releases".
  • Ágak és címkék esetén:
    • A mintában bárhol megjelenhet helyettesítő karakter.
  • Elérési utak esetén:
    • Az Azure DevOps Server 2022-ben és újabb verzióiban , beleértve az Azure DevOps Servicest is, egy helyettesítő karakter bárhol megjelenhet az elérési út mintáján belül, és használhatja * vagy ?használhatja.
    • Az Azure DevOps Server 2020-as és újabb operációs rendszerében végső karakterként szerepelhet * , de ez nem tesz mást, mint a címtárnév önmagában történő megadása. Előfordulhat, hogy nem szerepel * az elérésiút-szűrő közepén, és nem használja ?a elemet.
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR-eseményindítók

A lekéréses kérelem (PR) eseményindítói a folyamat futtatását okozzák, amikor megnyit egy lekéréses kérelmet, vagy amikor módosításokat küld hozzá. Az Azure Repos Gitben ez a funkció fiókszabályzatok használatával valósul meg. A lekéréses kérelem érvényesítésének engedélyezéséhez lépjen a kívánt ág ágszabályzataihoz, és konfigurálja az adott ág buildérvényesítési szabályzatát . További információ: Ágszabályzatok konfigurálása.

Ha nyitott lekéréses kérelem áll rendelkezésére, és leküldi a módosításokat a forráságba, több folyamat is futtatható:

  • A célág buildérvényesítési szabályzata által meghatározott folyamatok az egyesítési véglegesítésen (a lekéréses kérelem forrás- és célágai közötti egyesített kódon) futnak, függetlenül attól, hogy vannak-e leküldéses véglegesítések, amelyek üzenetei vagy leírásai tartalmazzák [skip ci] (vagy bármely változatát).
  • A leküldéses kérelem forráságának változásai által aktivált folyamatok, ha nincsenek leküldéses véglegesítések, amelyek üzenetei vagy leírásai (vagy bármely változata) tartalmaznak [skip ci] . Ha legalább egy leküldéses véglegesítés tartalmaz [skip ci], a folyamatok nem futnak.

Végül a lekéréses kérelem egyesítése után az Azure Pipelines futtatja a célágba irányuló leküldések által aktivált CI-folyamatokat, még akkor is, ha az egyesített véglegesítések egyes üzenetei vagy leírásai tartalmaznak [skip ci] (vagy bármely változata).

Feljegyzés

Az Azure Repos Git-adattár érvényesítési buildjeinek konfigurálásához a projekt projektgazdának kell lennie.

Feljegyzés

A lekéréses kérelmek piszkozatai akkor sem aktiválnak folyamatot, ha fiókszabályzatot konfigurál.

Az elágazásokból származó hozzájárulások ellenőrzése

Az Azure Repos-elágazásokból származó lekéréses kérelmek létrehozása nem különbözik az ugyanabban az adattárban vagy projektben lévő lekéréses kérelmek készítésétől. Az elágazásokat csak abban a szervezetben hozhatja létre, amelybe a projekt tartozik.

Feladat engedélyezési hatókörének korlátozása

Az Azure Pipelines számos biztonsági beállítást biztosít a folyamatok által futtatott feladat-engedélyezési hatókör konfigurálásához.

Feladat engedélyezési hatókörének korlátozása az aktuális projektre

Az Azure Pipelines két korlátozási feladat engedélyezési hatókörét biztosítja az aktuális projektbeállításokhoz :

  • A feladat engedélyezési hatókörének korlátozása a nem kiadási folyamatok aktuális projektjeire – Ez a beállítás a YAML-folyamatokra és a klasszikus buildelési folyamatokra vonatkozik. Ez a beállítás nem vonatkozik a klasszikus kiadási folyamatokra.
  • A feladat engedélyezési hatókörének korlátozása a kiadási folyamatok aktuális projektjeire – Ez a beállítás csak a klasszikus kiadási folyamatokra vonatkozik.

A folyamatok gyűjtemény hatókörű hozzáférési jogkivonatokkal futnak, kivéve, ha a folyamattípus megfelelő beállítása engedélyezve van. A Feladatengedélyezési hatókör korlátozása beállításokkal csökkentheti az aktuális projekt összes folyamatának hozzáférési hatókörét. Ez hatással lehet a folyamatra, ha a szervezet egy másik projektjében fér hozzá egy Azure Repos Git-adattárhoz.

Ha az Azure Repos Git-adattár más projektben van, mint a folyamat, és a folyamattípushoz tartozó korlátfeladat-engedélyezési hatókör-beállítás engedélyezve van, engedélyt kell adnia a folyamat buildszolgáltatás-identitására a második projektnek. További információ: A buildelési szolgáltatásfiók engedélyeinek kezelése.

Az Azure Pipelines biztonsági beállítást biztosít a folyamatok által futtatott feladat-engedélyezési hatókör konfigurálásához.

  • A feladat engedélyezési hatókörének korlátozása az aktuális projektre – Ez a beállítás a YAML-folyamatokra és a klasszikus buildelési folyamatokra vonatkozik. Ez a beállítás nem vonatkozik a klasszikus kiadási folyamatokra.

A folyamatok gyűjtemény hatókörű hozzáférési jogkivonatokkal futnak, kivéve, ha a feladat engedélyezési hatókörének korlátozása az aktuális projektre engedélyezve van. Ezzel a beállítással csökkentheti az aktuális projekt összes folyamatának hozzáférési hatókörét. Ez hatással lehet a folyamatra, ha a szervezet egy másik projektjében fér hozzá egy Azure Repos Git-adattárhoz.

Ha az Azure Repos Git-adattár más projektben van, mint a folyamat, és a Feladat engedélyezési hatókörének korlátozása beállítás engedélyezve van, engedélyt kell adnia a folyamat buildszolgáltatás-identitására a második projektnek. További információért lásd a feladatengedélyezési hatókört ismertető részt.

A feladat-engedélyezési hatókör korlátozásáról további információt a feladat-hozzáférési jogkivonatok ismertetése című témakörben talál.

A feladat engedélyezési hatókörének korlátozása a hivatkozott Azure DevOps-adattárakra

A folyamatok az engedélyezett projektek bármely Azure DevOps-adattárához hozzáférhetnek, ahogyan azt az előző Feladatengedélyezési hatókör korlátozása az aktuális projektszakaszra című cikkben leírtuk, kivéve, ha engedélyezve van a feladat engedélyezési hatókörének korlátozása az Azure DevOps-adattárakra való hivatkozáshoz. Ha ez a beállítás engedélyezve van, az összes folyamat hozzáférési hatókörét csak azokat az Azure DevOps-adattárakat csökkentheti, amelyekre kifejezetten hivatkozik az adattárat használó folyamatfeladat egy checkoutuses lépése vagy utasítása.

A beállítás konfigurálásához lépjen a Folyamatok lapra, Gépház a Szervezeti vagya Projektbeállítások között. Ha a szervezet szintjén engedélyezve van, a beállítás szürkén jelenik meg, és nem érhető el a projektbeállítások szintjén.

Ha a feladat engedélyezési hatókörének korlátozása a hivatkozott Azure DevOps-adattárakra engedélyezve van, a YAML-folyamatoknak explicit módon hivatkoznia kell a folyamatban használni kívánt Azure-adattárakra az adattárat használó feladat kivételi lépéseként. Az Azure Repos Git-adattárhoz tartozó szkriptelési feladatokkal és Git-parancsokkal nem tud kódot lekérni, kivéve, ha az adattárra először kifejezetten hivatkoznak.

Van néhány kivétel, amikor nem kell explicit módon hivatkoznia egy Azure-adattárra, mielőtt azt a folyamatban használná, amikor engedélyezve van a feladat engedélyezési hatókörének korlátozása az Azure DevOps-adattárakra való hivatkozáshoz.

  • Ha nem rendelkezik explicit kivételi lépéssel a folyamatban, az olyan, mintha van egy checkout: self lépése, és az self adattár ki van véve.
  • Ha szkripttel hajt végre írásvédett műveleteket egy nyilvános projekt adattárában, akkor nem kell a nyilvános projekt adattárára hivatkoznia egy checkout lépésben.
  • Ha olyan szkriptet használ, amely saját hitelesítést biztosít az adattárhoz(például pat), akkor nem kell erre az adattárra hivatkoznia egy checkout lépésben.

Ha például a feladat engedélyezési hatókörének korlátozása az Azure DevOps-adattárakra engedélyezve van, ha a folyamat a FabrikamProject/Fabrikam szervezet adattárában található, és szkripttel szeretné kivenni az FabrikamProject/FabrikamTools adattárat, akkor vagy egy checkout lépésben vagy utasítással uses kell hivatkoznia erre az adattárra.

Ha már kijelentkezteti a FabrikamTools folyamat adattárát egy kivételi lépéssel, a későbbiekben szkriptekkel kezelheti az adattárat.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

Feljegyzés

Számos forgatókönyv esetén a több adattárból történő kivétel kihasználható, így nem kell szkriptekkel további adattárakat kivenni a folyamatból. További információ: Több adattár megtekintése a folyamatban.

Adattárakhoz való hozzáférés védelme YAML-folyamatokban

A folyamatok az engedélyezett projektek bármely Azure DevOps-adattárához hozzáférhetnek az aktuális projektszakaszra vonatkozó korábbi korlátfeladat-engedélyezési hatókörben leírtak szerint, kivéve, ha engedélyezve van a YAML-folyamatok adattáraihoz való hozzáférés védelme. Ha ez a beállítás engedélyezve van, az összes folyamat hozzáférési hatókörét csak azokat az Azure DevOps-adattárakat csökkentheti, amelyekre kifejezetten hivatkozik az adattárat használó folyamatfeladat egy checkoutuses lépése vagy utasítása.

A beállítás konfigurálásához lépjen a Folyamatok lapra, Gépház a Szervezeti vagya Projektbeállítások között. Ha a szervezet szintjén engedélyezve van, a beállítás szürkén jelenik meg, és nem érhető el a projektbeállítások szintjén.

Fontos

A YAML-folyamatok adattáraihoz való hozzáférés alapértelmezés szerint engedélyezve van a 2020 májusa után létrehozott új szervezetek és projektek számára. Ha engedélyezve van a YAML-folyamatok adattáraihoz való hozzáférés védelme, a YAML-folyamatoknak explicit módon hivatkoznia kell a folyamatban használni kívánt Azure-adattárakra az adattárat használó feladat kivételi lépéseként. Az Azure Repos Git-adattárhoz tartozó szkriptelési feladatokkal és Git-parancsokkal nem tud kódot lekérni, kivéve, ha az adattárra először kifejezetten hivatkoznak.

Van néhány kivétel, amikor nem kell explicit módon hivatkoznia egy Azure Repos Git-adattárra, mielőtt a folyamatba használnák, amikor engedélyezve van a YAML-folyamatok adattáraihoz való hozzáférés védelme.

  • Ha nem rendelkezik explicit kivételi lépéssel a folyamatban, az olyan, mintha van egy checkout: self lépése, és az self adattár ki van véve.
  • Ha szkripttel hajt végre írásvédett műveleteket egy nyilvános projekt adattárában, akkor nem kell a nyilvános projekt adattárára hivatkoznia egy checkout lépésben.
  • Ha olyan szkriptet használ, amely saját hitelesítést biztosít az adattárhoz(például pat), akkor nem kell erre az adattárra hivatkoznia egy checkout lépésben.

Ha például engedélyezve van a YAML-folyamatok adattáraihoz való hozzáférés védelme, ha a folyamat a FabrikamProject/Fabrikam szervezet adattárában található, és szkripttel szeretné kivenni az FabrikamProject/FabrikamTools adattárat, akkor vagy egy checkout lépésben vagy utasítással uses kell hivatkoznia erre az adattárra.

Ha már kijelentkezteti a FabrikamTools folyamat adattárát egy kivételi lépéssel, a későbbiekben szkriptekkel kezelheti az adattárat.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Feljegyzés

Számos forgatókönyv esetén a több adattárból történő kivétel kihasználható, így nem kell szkriptekkel további adattárakat kivenni a folyamatból. További információ: Több adattár megtekintése a folyamatban.

Megrendelés

Amikor egy folyamat aktiválódik, az Azure Pipelines lekéri a forráskódot az Azure Repos Git-adattárból. Ennek különböző aspektusait szabályozhatja.

Feljegyzés

Amikor belefoglal egy kivételi lépést a folyamatba, a következő parancsot futtatjuk: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Ha ez nem felel meg az igényeinek, akkor dönthet úgy, hogy kizárja a beépített kivételt checkout: none , majd szkriptfeladatot használva végrehajtja a saját kivételét.

A Git előnyben részesített verziója

A Windows-ügynök saját Git-példányt tartalmaz. Ha inkább saját Gitet szeretne megadni a mellékelt másolat használata helyett, állítsa be System.PreferGitFromPath a következőt true: . Ez a beállítás mindig igaz a nem Windows-ügynökökre.

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

A beállítást a pathfolyamat Kivétel lépésében konfigurálhatja.

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

A beállítást a submodules folyamat Kivétel lépésében konfigurálhatja, ha almodulokból szeretne fájlokat letölteni.

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

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 található, mint a fent megadott Azure Repos Git-adattár. Ugyanezeket a hitelesítő adatokat használja az ügynök a fő adattár forrásainak lekéréséhez is.

    • Hozzáadva a fő adattárhoz viszonyított URL-cím használatával. Példa:

      • Ezt a kivételt a rendszer kivenné: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        Ebben a példában az almodul egy adattárra (FabrikamFiber) hivatkozik ugyanabban az Azure DevOps-szervezetben, de egy másik projektben (FabrikamFiberProject). Ugyanezeket a hitelesítő adatokat használja az ügynök a fő adattár forrásainak lekéréséhez is. Ehhez a feladat-hozzáférési jogkivonatnak hozzá kell férnie a második projekt adattárához. Ha a fenti szakaszban ismertetett módon korlátozta a feladat-hozzáférési jogkivonatot, akkor ezt nem fogja tudni megtenni. Engedélyezheti, hogy a feladat hozzáférési jogkivonata hozzáférjen az adattárhoz a második projektben, ha (a) explicit módon hozzáférést ad a projekt buildszolgáltatás-fiókjához a második projektben, vagy (b) gyűjtemény hatókörű hozzáférési jogkivonatokat használ a teljes szervezet projekthatókörű jogkivonatai helyett. További információ ezekről a lehetőségekről és azok biztonsági következményeiről: Access-adattárak, összetevők és egyéb erőforrások.

      • Ezt nem venné ki a rendszer: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

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 tárolva, vagy ha a feladat-hozzáférési jogkivonat nem fér hozzá egy másik projekt adattárához.

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_STRING>" submodule update --init --recursive

Mindenképpen cserélje le a "<BA Standard kiadás 64_ENCODED_STRING>" kifejezést a Base64 kódolású "pat:token" sztringre.

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.

Címkék szinkronizálása

Fontos

A szinkronizálási címkék funkció az Azure Repos Gitben az Azure DevOps Server 2022.1 és újabb verzióival támogatott.

A kivételi lépés a --tags Git-adattár tartalmának beolvasásakor használja a lehetőséget. Ez azt eredményezi, hogy a kiszolgáló lekéri az összes címkét, valamint az összes olyan objektumot, amelyekre ezek a címkék mutatnak. Ez növeli a feladat folyamaton belüli futtatásának idejét, különösen akkor, ha nagy tárháza van több címkével. Ezenkívül a kivételi lépés szinkronizálja a címkéket akkor is, ha engedélyezi a sekély beolvasási lehetőséget, így valószínűleg nem tudja a célját. A Git-adattárból lekért vagy lekért adatok mennyiségének csökkentése érdekében a Microsoft új lehetőséget adott a kivételre a címkék szinkronizálási viselkedésének szabályozásához. Ez a lehetőség a klasszikus és a YAML-folyamatokban is elérhető.

Azt, hogy szinkronizálja-e a címkéket egy adattár kivételekor, konfigurálható-e a YAML-ben a fetchTags tulajdonság beállításával, illetve a felhasználói felületen a Szinkronizálási címkék beállítás konfigurálásával.

A beállítást a fetchTagsfolyamat Kivétel lépésében konfigurálhatja.

A BEÁLLÍTÁS YAML-ben való konfigurálásához állítsa be a tulajdonságot fetchTags .

steps:
- checkout: self
  fetchTags: true

Ezt a beállítást a folyamatbeállítások felhasználói felületén található Szinkronizálás címkék beállításával is konfigurálhatja.

  1. Szerkessze a YAML-folyamatot, és válassza a További műveletek, triggerek lehetőséget.

    Képernyőkép a további eseményindítók menüjéről.

  2. Válassza a YAML, a Források lekérése lehetőséget.

    A Források lekérése képernyőképe.

  3. Konfigurálja a Szinkronizálási címkék beállítást.

    Képernyőkép a Címkék szinkronizálása beállításról.

Feljegyzés

Ha explicit módon állítja be fetchTags a checkout lépést, a beállítás elsőbbséget élvez a folyamatbeállítások felhasználói felületén konfigurált beállítással szemben.

Alapértelmezett viselkedés

Feljegyzés

Ha explicit módon állítja be fetchTags a checkout lépést, a beállítás elsőbbséget élvez a folyamatbeállítások felhasználói felületén konfigurált beállítással szemben.

Sekély lekérés

Előfordulhat, hogy korlátozni szeretné, hogy a korábbi verziókban milyen messze legyen a letöltés. 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.

Fontos

A 2022. szeptemberi Azure DevOps sprint 209-frissítés után létrehozott új folyamatok alapértelmezés szerint engedélyezik a Shallow beolvasást, és 1 mélységben vannak konfigurálva. Korábban az alapértelmezett nem volt a sekély beolvasás. A folyamat ellenőrzéséhez tekintse meg a Sekély beolvasás beállítást a folyamatbeállítások felhasználói felületén, az alábbi szakaszban leírtak szerint.

A beállítást a fetchDepthfolyamat Kivétel lépésében konfigurálhatja.

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

A beolvasási mélységet úgy is konfigurálhatja, hogy megadja a Sekély mélység beállítást a folyamatbeállítások felhasználói felületén.

  1. Szerkessze a YAML-folyamatot, és válassza a További műveletek, triggerek lehetőséget.

    Képernyőkép a további eseményindítók menüjéről.

  2. Válassza a YAML, a Források lekérése lehetőséget.

    A Források lekérése képernyőképe.

  3. Konfigurálja a Sekély beolvasás beállítást. Törölje a jelet a Sekély beolvasás jelölőnégyzetből a sekély beolvasás letiltásához, vagy jelölje be a jelölőnégyzetet, és adjon meg egy mélységet a sekély lehívás engedélyezéséhez.

    Képernyőkép a beállításokról.

Feljegyzés

Ha explicit módon állítja be fetchDepth a checkout lépést, a beállítás elsőbbséget élvez a folyamatbeállítások felhasználói felületén konfigurált beállítással szemben. A beállítás fetchDepth: 0 lekéri az összes előzményt, és felülbírálja a Shallow beolvasási beállítást.

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 folyamat indításakor 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.

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

Előfordulhat, hogy kihagyja az új véglegesítések beolvasását. 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 olyan automatizálást (például néhány szkriptet), amelyek nem függnek a verziókövetésben lévő kódtól.

A Forrásszinkronizálás mellőzése beállítást a folyamat Kivétel lépésében konfigurálhatja a beállítássalcheckout: none.

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

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.

Build tisztítása

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.

A beállítást a cleanfolyamat Kivétel lépésében konfigurálhatja.

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

Ha clean a buildelési folyamatra true van állítva, a rendszer 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

További beállításokért konfigurálhatja a workspace feladat beállításait.

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

Ez a következő tiszta lehetőségeket nyújtja.

  • kimenetek: Ugyanaz a művelet, mint az előző kivételi feladatban leírt tiszta beállítás, valamint: 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.

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

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

Ez a beállítás jelenleg nem konfigurálható a YAML-ben, de a klasszikus szerkesztőben is. YAML-folyamat szerkesztésekor a YAML-szerkesztő menüjében az Eseményindítók lehetőséget választva érheti el a klasszikus szerkesztőt.

Git-beállítások konfigurálása, YAML.

A klasszikus szerkesztőben válassza a YAML lehetőséget, válassza a Források lekérése feladatot, majd konfigurálja ott a kívánt tulajdonságokat.

A klasszikus szerkesztőben válassza a YAML > Get sources (Források lekérése) lehetőséget.

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.

GYIK

Az Azure Repos-integrációval kapcsolatos problémák három kategóriába sorolhatók:

Sikertelen eseményindítók

Most hoztam létre egy új YAML-folyamatot CI/PR-triggerekkel, de a folyamat nem aktiválódik.

Kövesse az alábbi lépéseket a sikertelen eseményindítók hibaelhárításához:

  • Felül vannak bírálva a YAML CI- vagy PR-eseményindítók a felhasználói felületen a folyamatbeállítások alapján? A folyamat szerkesztése közben válassza a ... és az Eseményindítók lehetőséget.

    Folyamatbeállítások felhasználói felülete.

    Tekintse meg a YAML-eseményindító felülbírálása beállítást az adattárhoz elérhető triggertípusok (folyamatos integráció vagy lekéréses kérelmek érvényesítése) esetében.

    Itt bírálja felül a YAML-eseményindítót.

  • Konfigurálja a PR-eseményindítót a YAML-fájlban vagy az adattár ágszabályzataiban? Azure Repos Git-adattár esetén nem konfigurálhat PR-eseményindítót a YAML-fájlban. Ágszabályzatokat kell használnia.

  • A folyamat szüneteltetve van vagy le van tiltva? Nyissa meg a folyamat szerkesztőjében, majd válassza a Gépház az ellenőrzéshez. Ha a folyamat szüneteltetve van vagy le van tiltva, az eseményindítók nem működnek.

  • Frissítette a YAML-fájlt a megfelelő ágban? Ha leküld egy frissítést egy ágba, akkor az ugyanabban az ágban lévő YAML-fájl szabályozza a CI viselkedését. Ha frissítést küld egy forráságba, akkor a forráság és a célág egyesítéséből eredő YAML-fájl szabályozza a pr viselkedését. Győződjön meg arról, hogy a megfelelő ágban lévő YAML-fájl rendelkezik a szükséges CI- vagy PR-konfigurációval.

  • Helyesen konfigurálta az eseményindítót? YAML-eseményindító definiálásakor megadhatja az ágak, címkék és útvonalak belefoglalási és kizárási záradékait is. Győződjön meg arról, hogy a belefoglalási záradék megfelel a véglegesítés részleteinek, és hogy a kizárási záradék nem zárja ki őket. Ellenőrizze az eseményindítók szintaxisát, és győződjön meg arról, hogy azok pontosak.

  • Változókat használt az eseményindító vagy az elérési utak definiálásához? Ez nem támogatott.

  • Sablonokat használt a YAML-fájlhoz? Ha igen, győződjön meg arról, hogy az eseményindítók a fő YAML-fájlban vannak definiálva. A sablonfájlokban definiált triggerek nem támogatottak.

  • Kizárta azokat az ágakat vagy útvonalakat, amelyekbe leküldte a módosításokat? A teszteléshez küldjön egy módosítást egy belefoglalt ágban lévő elérési útra. Vegye figyelembe, hogy az eseményindítók elérési útjai megkülönböztetik a kis- és nagybetűket. Az eseményindítók elérési útjainak megadásakor győződjön meg arról, hogy ugyanazt a esetet használja, mint a valódi mappáké.

  • Csak leküldtél egy új ágat? Ha igen, előfordulhat, hogy az új ág nem indít el új futtatásokat. Lásd a "Triggerek viselkedése új ágak létrehozásakor" című szakaszt.

A CI- vagy PR-triggerek jól működnek. De most már nem dolgoznak.

Először tekintse át az előző kérdés hibaelhárítási lépéseit. Ezután kövesse az alábbi további lépéseket:

  • Vannak egyesítési ütközések a lekéréses kérelemben? Olyan lekéréses kérelem esetén, amely nem aktivált egy folyamatot, nyissa meg, és ellenőrizze, hogy van-e egyesítési ütközése. Az egyesítési ütközés feloldása.

  • Késést tapasztal a leküldéses vagy pr-események feldolgozásában? Ezt általában úgy ellenőrizheti, hogy a probléma egyetlen folyamatra vonatkozik-e, vagy a projekt összes folyamatára vagy adattárára jellemző. Ha egy leküldéses vagy egy leküldéses frissítés az adattárak bármelyikére jelentkezik, előfordulhat, hogy késések tapasztalhatók a frissítési események feldolgozása során. Ellenőrizze, hogy szolgáltatáskimaradást tapasztalunk-e az állapotoldalunkon. Ha az állapotlapon probléma jelenik meg, akkor a csapatunknak már hozzá kellett kezdenie a munkához. A probléma frissítéseit gyakran ellenőrizze a lapon.

Nem akarom, hogy a felhasználók felülbírálják az eseményindítók ágainak listáját a YAML-fájl frissítésekor. Hogyan tehetem ezt meg?

A közreműködői kóddal rendelkező felhasználók frissíthetik a YAML-fájlt, és további ágakat is belefoglalhatnak vagy kizárhatnak. Ennek eredményeképpen a felhasználók belefoglalhatják a saját funkciójukat vagy felhasználói águkat a YAML-fájljukba, és leküldhetik a frissítést egy szolgáltatásba vagy felhasználói ágba. Ez azt okozhatja, hogy a folyamat az adott ág összes frissítéséhez aktiválódik. Ha meg szeretné akadályozni ezt a viselkedést, a következőt teheti:

  1. Szerkessze a folyamatot az Azure Pipelines felhasználói felületén.
  2. Lépjen az Eseményindítók menüre.
  3. Itt válassza a YAML folyamatos integrációs eseményindító felülbírálása lehetőséget.
  4. Adja meg az eseményindítóhoz felvenni vagy kizárni kívánt ágakat.

Az alábbi lépések végrehajtásával a YAML-fájlban megadott CI-eseményindítók figyelmen kívül lesznek hagyva.

Több adattáram is van a YAML-folyamatban. Hogyan állíthatok be triggereket az egyes adattárakhoz?

Lásd a triggereket a Több adattár használata témakörben.

Sikertelen kivétel

A következő hibaüzenet jelenik meg a naplófájlban a kivételi lépés során. Hogyan kijavítani?

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

Kövesse az alábbi lépéseket a sikertelen kivétel hibaelhárításához:

  • Létezik még az adattár? Először is győződjön meg róla, hogy megnyitja a Tárak lapon.

  • Szkripttel fér hozzá az adattárhoz? Ha igen, ellenőrizze a feladat engedélyezési hatókörének korlátozását az Azure DevOps-adattárak beállítására való hivatkozáshoz. Ha a feladat engedélyezési hatókörének korlátozása a hivatkozott Azure DevOps-adattárakra engedélyezve van, akkor csak akkor tekintheti meg az Azure Repos Git-adattárakat szkriptek használatával, ha a folyamat először kifejezetten hivatkozik rájuk.

  • Mi a folyamat feladat-engedélyezési hatóköre ?

    • Ha a hatókör gyűjtemény:

      • Ez időszakos hiba lehet. Futtassa újra a folyamatot.
      • Lehetséges, hogy valaki eltávolította a Project Collection Build Service-fiókhoz való hozzáférést.
        • Nyissa meg annak a projektnek a Project beállításait , amelyben az adattár létezik. Válassza az Adattárak > adott tárház, majd a Biztonság lehetőséget.>
        • Ellenőrizze, hogy létezik-e a Project Collection Build Service (a gyűjtemény neve) a felhasználók listájában.
        • Ellenőrizze, hogy a fiók rendelkezik-e létrehozási címkével és olvasási hozzáféréssel.

    • Ha a hatókör projekt:

      • Az adattár ugyanabban a projektben található, mint a folyamat?
        • Igen:
          • Ez időszakos hiba lehet. Futtassa újra a folyamatot.
          • Lehetséges, hogy valaki eltávolította a Project Build Service-fiókhoz való hozzáférést.
            • Nyissa meg annak a projektnek a Project beállításait , amelyben az adattár létezik. Válassza az Adattárak > adott tárház, majd a Biztonság lehetőséget.>
            • Ellenőrizze, hogy a projektnév buildszolgáltatása (a gyűjtemény neve) létezik-e a felhasználók listájában.
            • Ellenőrizze, hogy a fiók rendelkezik-e létrehozási címkével és olvasási hozzáféréssel.
        • Nem:

Helytelen verzió

A folyamat a YAML-fájl nem megfelelő verzióját használja. Ennek mi az oka?

  • CI-eseményindítók esetén a leküldéses ágban lévő YAML-fájl kiértékelése ellenőrzi, hogy futtassa-e a CI-buildet.
  • Pr-eseményindítók esetén a KÉRELEM forrás- és célágainak egyesítéséből eredő YAML-fájl kiértékelése annak érdekében történik, hogy futtasson-e pr-buildet.