GitHub-adattárak létrehozása

Azure DevOps Services

Az Azure Pipelines automatikusan létrehozhat és érvényesíthet minden lekéréses kérelmet, és véglegesítheti a GitHub-adattárat. Ez a cikk a GitHub és az Azure Pipelines közötti integráció konfigurálását ismerteti.

Ha még nem ismerkedik a GitHub-folyamatintegrációval, kövesse az első folyamat létrehozása című cikk lépéseit. Térjen vissza ehhez a cikkhez, és tudjon meg többet a GitHub és az Azure Pipelines közötti integráció konfigurálásáról és testreszabásáról.

Szervezetek és felhasználók

A GitHub és az Azure Pipelines két független szolgáltatás, amelyek jól integrálhatók egymással. Mindegyikük saját szervezettel és felhasználókezeléssel rendelkezik. Ez a szakasz javaslatot tesz arra, hogyan replikálhatja a szervezetet és a felhasználókat a GitHubról az Azure Pipelinesba.

Szervezetek

A GitHub struktúrája adattárakat tartalmazó szervezetekből és felhasználói fiókokból áll. Tekintse meg a GitHub dokumentációját.

Az Azure DevOps struktúrája projekteket tartalmazó szervezetekből áll. Lásd: A szervezeti struktúra megtervezése.

Az Azure DevOps a Következőkkel tükrözheti a GitHub-struktúrát:

• DevOps-szervezet a GitHub-szervezethez vagy felhasználói fiókhoz
• DevOps-projektek a GitHub-adattárakhoz

Azonos struktúra beállítása az Azure DevOpsban:

1. Hozzon létre egy DevOps-szervezetet, amely a GitHub-szervezetről vagy a felhasználói fiókról kapta a nevét. A következő URL-cím https://dev.azure.com/your-organizationfog rendelkezni: .
2. A DevOps-szervezetben hozzon létre az adattárakról elnevezett projekteket. Olyan URL-címekkel rendelkeznek, mint a https://dev.azure.com/your-organization/your-repository.
3. A DevOps Projectben hozzon létre az általuk létrehozott GitHub-szervezetről és adattárról elnevezett folyamatokat, például your-organization.your-repository. Akkor egyértelmű, hogy mely adattárakhoz valók.

Ezt a mintát követve a GitHub-adattárak és az Azure DevOps-projektek egyező URL-elérési utakat fognak tartalmazni. Példa:

Szolgáltatás	URL-cím
GitHub	https://github.com/python/cpython
Azure DevOps	https://dev.azure.com/python/cpython

Felhasználók

A GitHub-felhasználók nem kapnak automatikusan hozzáférést az Azure Pipelineshoz. Az Azure Pipelines nem ismeri a GitHub-identitásokat. Ezért az Azure Pipelines nem konfigurálható úgy, hogy a GitHub-identitás és e-mail-cím használatával automatikusan értesítse a felhasználókat a buildelési hibáról vagy egy pr-érvényesítési hibáról. A GitHub-felhasználók replikálásához kifejezetten létre kell hoznia új felhasználókat az Azure Pipelinesban. Miután létrehozott új felhasználókat, konfigurálhatja az engedélyeiket az Azure DevOpsban, hogy azok tükrözzék a GitHubon lévő engedélyeiket. Az értesítéseket a DevOpsban is konfigurálhatja a DevOps-identitásukkal.

A GitHub szervezeti szerepkörei

A GitHub szervezeti tagszerepkörei a (csereyour-organization) helyen https://github.com/orgs/your-organization/people találhatók.

A DevOps-szervezet tagengedélyei a (csereyour-organization) helyen https://dev.azure.com/your-organization/_settings/security találhatók.

A GitHub-szervezetek szerepkörei és az Azure DevOps-szervezetek egyenértékű szerepkörei az alábbiakban láthatók.

A GitHub szervezeti szerepköre	DevOps-szervezet megfelelője
Tulajdonos	A Project Collection Administrators
Számlázáskezelő	A Project Collection Administrators
Tag	Project Collection Valid UsersA . Alapértelmezés szerint a tagcsoport nem rendelkezik új projektek létrehozására vonatkozó engedéllyel. Az engedély módosításához állítsa be a csoport engedélyét Create new projects Allow, vagy hozzon létre egy új csoportot a szükséges engedélyekkel.

GitHub-felhasználói fiókszerepkörök

Egy GitHub-felhasználói fiók egy szerepkörrel rendelkezik, amely a fiók tulajdonjoga.

A DevOps-szervezet tagengedélyei a (csereyour-organization) helyen https://dev.azure.com/your-organization/_settings/security találhatók.

A GitHub felhasználói fiók szerepköre az alábbiak szerint képezi le a DevOps-szervezet engedélyeit.

GitHub felhasználói fiók szerepkör	DevOps-szervezet megfelelője
Tulajdonos	A Project Collection Administrators

GitHub-adattár engedélyei

A GitHub-adattár engedélyei a következő helyen https://github.com/your-organization/your-repository/settings/collaboration találhatók: (csere your-organization és your-repository).

A DevOps-projekt engedélyei a következő helyen https://dev.azure.com/your-organization/your-project/_settings/security találhatók: (csere your-organization és your-project).

A GitHub-adattárak és az Azure DevOps-projektek egyenértékű engedélyei a következők.

GitHub-adattár engedélye	DevOps-projekt egyenértékű
Rendszergazda	A Project Administrators
Írás	A Contributors
Olvasás	A Readers

Ha a GitHub-adattár engedélyt ad a csapatoknak, létrehozhat egyező csapatokat az Teams Azure DevOps-projektbeállítások szakaszában. Ezután adja hozzá a csoportokat a fenti biztonsági csoportokhoz, a felhasználókhoz hasonlóan.

Folyamatspecifikus engedélyek

Ha engedélyeket szeretne adni egy DevOps-projekt adott folyamatainak felhasználóinak vagy csapatainak, kövesse az alábbi lépéseket:

1. Látogasson el a projekt Folyamatok lapjára (például https://dev.azure.com/your-organization/your-project/_build).
2. Válassza ki azt a folyamatot, amelyhez adott engedélyeket szeretne beállítani.
3. A"..." helyi menüben válassza a Biztonság lehetőséget.
4. Válassza a Hozzáadás... lehetőséget egy adott felhasználó, csapat vagy csoport hozzáadásához és a folyamat engedélyeinek testreszabásához.

Hozzáférés a GitHub-adattárakhoz

YAML

Új folyamatot úgy hozhat létre, hogy először kiválaszt egy GitHub-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.

Klasszikus

Új folyamatot úgy hozhat létre, hogy először a GitHubot választja az adattártípushoz, majd az egyik adattárat, amelyhez hozzáféréssel rendelkezik.

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.

A folyamat létrehozásakor három hitelesítési típus biztosít hozzáférést az Azure Pipelines számára a GitHub-adattárakhoz.

Hitelesítés típusa	A folyamatok a következő használatával futnak:	A GitHub-ellenőrzések működése
1. GitHub-alkalmazás	Az Azure Pipelines-identitás	Igen
2. OAuth	Személyes GitHub-identitás	Nem
3. Személyes hozzáférési jogkivonat (PAT)	Személyes GitHub-identitás	Nem

GitHub-alkalmazáshitelesítés

Az Azure Pipelines GitHub-alkalmazás a folyamatos integrációs folyamatokhoz ajánlott hitelesítési típus. Miután telepítette a GitHub-alkalmazást a GitHub-fiókjában vagy szervezetében, a folyamat a személyes GitHub-identitás használata nélkül fog futni. A buildek és a GitHub állapotfrissítései az Azure Pipelines-identitás használatával lesznek végrehajtva. Az alkalmazás a GitHub-ellenőrzőkkel együttműködve megjeleníti a buildelési, tesztelési és kódlefedettségi eredményeket a GitHubon.

A GitHub-alkalmazás használatához telepítse a GitHub-szervezetében vagy felhasználói fiókjában néhány vagy az összes adattárhoz. A GitHub-alkalmazás telepíthető és eltávolítható az alkalmazás kezdőlapjáról.

A telepítés után a GitHub-alkalmazás lesz az Azure Pipelines alapértelmezett hitelesítési módszere a GitHubon (az OAuth helyett), amikor a folyamatok létrejönnek az adattárakhoz.

Ha egy GitHub-szervezet összes adattárához telepíti a GitHub-alkalmazást, nem kell aggódnia amiatt, hogy az Azure Pipelines tömeges e-maileket küld, vagy automatikusan beállítja a folyamatokat az Ön nevében. Az alkalmazás minden adattárhoz való telepítésének alternatívaként az adattárgazdák egyenként telepíthetik az egyes adattárakhoz. Ez több munkát igényel a rendszergazdák számára, de nincs előnye és hátránya.

A GitHubon szükséges engedélyek

Az Azure Pipelines GitHub-alkalmazás telepítéséhez a GitHub-szervezet tulajdonosának vagy adattárának rendszergazdájának kell lennie. Emellett ahhoz, hogy folyamatos integrációs és lekéréses kérelem-eseményindítókkal rendelkező GitHub-adattárhoz hozzon létre egy folyamatot, konfigurálnia kell a szükséges GitHub-engedélyeket. Ellenkező esetben az adattár nem jelenik meg az adattár listában egy folyamat létrehozásakor. Az adattár hitelesítési típusától és tulajdonjogától függően győződjön meg arról, hogy a megfelelő hozzáférés van konfigurálva.

• Ha az adattár a személyes GitHub-fiókjában található, telepítse az Azure Pipelines GitHub-alkalmazást a személyes GitHub-fiókjába, és ezt az adattárat listázhatja a folyamat Azure Pipelinesban való létrehozásakor.

• Ha az adattár valaki más személyes GitHub-fiókjában található, a másik személynek telepítenie kell az Azure Pipelines GitHub alkalmazást a személyes GitHub-fiókjába. Közreműködőként hozzá kell adnia az adattár beállításaihoz a "Közreműködők" területen. Fogadja el a meghívót, hogy közreműködő legyen az Ön számára e-mailben elküldött hivatkozás használatával. Ezt követően létrehozhat egy folyamatot az adattárhoz.

• Ha az adattár az Ön tulajdonában lévő GitHub-szervezetben található, telepítse az Azure Pipelines GitHub alkalmazást a GitHub-szervezetben. Közreműködőként is hozzá kell adnia, vagy a csapatát hozzá kell adni az adattár "Közreműködők és csapatok" csoportjának beállításaihoz.

• Ha az adattár egy olyan GitHub-szervezetben található, amelyet valaki más birtokol, a GitHub-szervezet tulajdonosának vagy adattár-rendszergazdájának telepítenie kell az Azure Pipelines GitHub alkalmazást a szervezetben. Közreműködőként kell hozzáadnia, vagy hozzá kell adnia a csapatát az adattár "Közreműködők és csapatok" csoportjának beállításaihoz. Fogadja el a meghívót, hogy közreműködő legyen az Ön számára e-mailben elküldött hivatkozás használatával.

GitHub-alkalmazásengedélyek

A GitHub-alkalmazás a következő engedélyeket kéri a telepítés során:

Engedély	Hogyan használja az Azure Pipelines az engedélyt?
Kódhoz való hozzáférés írása	Az Azure Pipelines csak szándékos művelettel egyszerűsíti a folyamat létrehozását azáltal, hogy yaML-fájlt véglegesít a GitHub-adattár egy kiválasztott ágára.
Metaadatokhoz való hozzáférés olvasása	Az Azure Pipelines lekéri a GitHub-metaadatokat az adattár, az ágak és a buildekkel kapcsolatos problémák megjelenítéséhez a build összegzésében.
Olvasási és írási hozzáférés az ellenőrzésekhez	Az Azure Pipelines felolvassa és megírja saját buildelési, tesztelési és kódlefedettségi eredményeit, hogy megjelenjenek a GitHubon.
Olvasási és írási hozzáférés lekéréses kérelmekhez	Az Azure Pipelines csak szándékos művelettel egyszerűsíti a folyamat létrehozását egy olyan YAML-fájl lekéréses kérésének létrehozásával, amely a GitHub-adattár egy kiválasztott ágához lett véglegesített. A folyamatok lekérik a kérés metaadatait, hogy megjelenjenek a lekéréses kérelmekhez társított buildösszegzőkben.

A GitHub-alkalmazás telepítésének hibaelhárítása

A GitHub a következőhöz hasonló hibaüzenetet jeleníthet meg:

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

Ez azt jelenti, hogy a GitHub-alkalmazás valószínűleg már telepítve van a szervezet számára. Amikor létrehoz egy folyamatot egy adattárhoz a szervezetben, a GitHub-alkalmazás automatikusan a GitHubhoz való csatlakozáshoz lesz használva.

Folyamatok létrehozása több Azure DevOps-szervezetben és -projektben

A GitHub-alkalmazás telepítése után folyamatokat hozhat létre a szervezet adattáraihoz különböző Azure DevOps-szervezetekben és -projektekben. Ha azonban több Azure DevOps-szervezetben hoz létre folyamatokat egyetlen adattárhoz, akkor csak az első szervezet folyamatait aktiválhatja automatikusan a GitHub véglegesítési vagy lekéréses kérései. A manuális vagy ütemezett buildek továbbra is lehetségesek a másodlagos Azure DevOps-szervezetekben.

OAuth-hitelesítés

Az OAuth a legegyszerűbb hitelesítési típus a személyes GitHub-fiók adattárainak használatbavételéhez. A GitHub állapotfrissítései a személyes GitHub-identitás nevében lesznek végrehajtva. Ahhoz, hogy a folyamatok működjenek, az adattár hozzáférésének aktívnak kell maradnia. Egyes GitHub-funkciók, például a Csekkek, nem érhetők el az OAuth szolgáltatással, és a GitHub-alkalmazásra van szükség.

Az OAuth használatához válassza a Másik kapcsolat kiválasztása lehetőséget a folyamat létrehozásakor az adattárak listája alatt. Ezután válassza az Engedélyezés lehetőséget a GitHubra való bejelentkezéshez és az OAuthtal való engedélyezéshez. A rendszer egy OAuth-kapcsolatot ment az Azure DevOps-projektbe későbbi használatra, és a létrehozott folyamatban használja.

A GitHubon szükséges engedélyek

Ha folyamatos integrációs és lekéréses kérelem-eseményindítókkal rendelkező GitHub-adattárhoz szeretne folyamatot létrehozni, konfigurálnia kell a szükséges GitHub-engedélyeket. Ellenkező esetben az adattár nem jelenik meg az adattár listában egy folyamat létrehozásakor. Az adattár hitelesítési típusától és tulajdonjogától függően győződjön meg arról, hogy a megfelelő hozzáférés van konfigurálva.

• Ha az adattár a személyes GitHub-fiókjában található, legalább egyszer hitelesítse magát a GitHubon az OAuth használatával a személyes GitHub-fiók hitelesítő adataival. Ez az Azure DevOps projektbeállításaiban, a Pipelines > Service-kapcsolatok > Új szolgáltatáskapcsolat > GitHub-engedélyezés > területén végezhető el. Adjon hozzáférést az Azure Pipelinesnak az adattárakhoz az "Engedélyek" területen.

• Ha az adattár valaki más személyes GitHub-fiókjában található, legalább egyszer a másik személynek hitelesítenie kell magát a GitHubon az OAuth használatával a személyes GitHub-fiók hitelesítő adataival. Ez az Azure DevOps projektbeállításaiban, a Pipelines > Service-kapcsolatok > Új szolgáltatáskapcsolat > GitHub-engedélyezés > területén végezhető el. A másik személynek hozzáférést kell adnia az Azure Pipelines számára az adattárakhoz az "Engedélyek" területen. Közreműködőként hozzá kell adnia az adattár beállításaihoz a "Közreműködők" területen. Fogadja el a meghívót, hogy közreműködő legyen az Ön számára e-mailben elküldött hivatkozás használatával.

• Ha az adattár egy Ön tulajdonában lévő GitHub-szervezetben található, legalább egyszer hitelesíthet a GitHubon OAuth használatával a személyes GitHub-fiók hitelesítő adataival. Ez az Azure DevOps projektbeállításaiban, a Pipelines > Service-kapcsolatok > Új szolgáltatáskapcsolat > GitHub-engedélyezés > területén végezhető el. Itt adhat hozzáférést az Azure Pipelinesnak a szervezet számára a "Szervezeti hozzáférés" területen. Közreműködőként kell hozzáadnia, vagy hozzá kell adnia a csapatát az adattár "Közreműködők és csapatok" csoportjának beállításaihoz.

• Ha az adattár egy Olyan GitHub-szervezetben található, amelynek valaki más a tulajdonosa, legalább egyszer a GitHub-szervezet tulajdonosának az OAuth használatával kell hitelesítenie a GitHubon a személyes GitHub-fiók hitelesítő adataival. Ez az Azure DevOps projektbeállításaiban, a Pipelines > Service-kapcsolatok > Új szolgáltatáskapcsolat > GitHub-engedélyezés > területén végezhető el. A szervezet tulajdonosának hozzáférést kell biztosítania az Azure Pipelines számára a szervezet számára a "Szervezeti hozzáférés" területen. Közreműködőként kell hozzáadnia, vagy hozzá kell adnia a csapatát az adattár "Közreműködők és csapatok" csoportjának beállításaihoz. Fogadja el a meghívót, hogy közreműködő legyen az Ön számára e-mailben elküldött hivatkozás használatával.

OAuth-hozzáférés visszavonása

Miután engedélyezi az Azure Pipelines számára az OAuth használatát, később visszavonhatja és megakadályozhatja a további használatot, látogasson el az OAuth Apps webhelyre a GitHub beállításai között. Az Azure DevOps-projekt beállításai között a GitHub-szolgáltatáskapcsolatok listájából is törölheti.

Személyes hozzáférési jogkivonat (PAT) hitelesítése

A PAT-k gyakorlatilag megegyeznek az OAuth-zal, de lehetővé teszik annak szabályozását, hogy mely engedélyeket adják az Azure Pipelinesnak. A buildek és a GitHub állapotfrissítései a személyes GitHub-identitás nevében lesznek végrehajtva. Ahhoz, hogy a buildek működjenek, az adattár hozzáférésének aktívnak kell maradnia.

Pat létrehozásához látogasson el a Személyes hozzáférési jogkivonatokra a GitHub beállításai között. A szükséges engedélyek a következőkrepo: , admin:repo_hookread:userés user:email. Ezek ugyanazok az engedélyek, amelyek a fenti OAuth használatakor szükségesek. Másolja a létrehozott PAT-t a vágólapra, és illessze be egy új GitHub-szolgáltatáskapcsolatba az Azure DevOps-projekt beállításai között. A későbbi visszahíváshoz nevezze el a szolgáltatáskapcsolatot a GitHub-felhasználónév után. Az Azure DevOps-projektben a folyamat létrehozásakor később is elérhető lesz.

A GitHubon szükséges engedélyek

Ha folyamatos integrációs és lekéréses kérelem-eseményindítókkal rendelkező GitHub-adattárhoz szeretne folyamatot létrehozni, konfigurálnia kell a szükséges GitHub-engedélyeket. Ellenkező esetben az adattár nem jelenik meg az adattár listában egy folyamat létrehozásakor. Az adattár hitelesítési típusától és tulajdonjogától függően győződjön meg arról, hogy a következő hozzáférés van konfigurálva.

• Ha az adattár a személyes GitHub-fiókjában található, a PAT-nak rendelkeznie kell a szükséges hozzáférési hatóköröknek a Személyes hozzáférési jogkivonatok alatt: repo, admin:repo_hook, read:userés user:email.

• Ha az adattár valaki más személyes GitHub-fiókjában található, akkor a PAT-nak rendelkeznie kell a szükséges hozzáférési hatókörekkel a Személyes hozzáférési jogkivonatok alatt: repo, admin:repo_hook, read:userés user:email. Közreműködőként hozzá kell adnia az adattár beállításaihoz a "Közreműködők" területen. Fogadja el a meghívót, hogy közreműködő legyen az Ön számára e-mailben elküldött hivatkozás használatával.

• Ha az adattár egy Ön tulajdonában lévő GitHub-szervezetben található, a PAT-nak rendelkeznie kell a szükséges hozzáférési hatókörökvel a Személyes hozzáférési jogkivonatok alatt: repo, admin:repo_hook, read:userés user:email. Közreműködőként kell hozzáadnia, vagy hozzá kell adnia a csapatát az adattár "Közreműködők és csapatok" csoportjának beállításaihoz.

• Ha az adattár egy Olyan GitHub-szervezetben található, amelyet valaki más birtokol, a PAT-nak rendelkeznie kell a szükséges hozzáférési hatókörökvel a Személyes hozzáférési jogkivonatok alatt: repo, admin:repo_hook, read:userés user:email. Közreműködőként kell hozzáadnia, vagy hozzá kell adnia a csapatát az adattár "Közreműködők és csapatok" csoportjának beállításaihoz. Fogadja el a meghívót, hogy közreműködő legyen az Ön számára e-mailben elküldött hivatkozás használatával.

PAT-hozzáférés visszavonása

Miután engedélyezi az Azure Pipelines számára a PAT használatát, később törölheti és megakadályozhatja a további használatot, látogasson el a Személyes hozzáférési jogkivonatokra a GitHub beállításai között. Az Azure DevOps-projekt beállításai között a GitHub-szolgáltatáskapcsolatok listájából is törölheti.

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.

YAML

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 exclude include 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 B C 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.

Klasszikus

Az Eseményindítók lapon válassza a Folyamatos integráció engedélyezése lehetőséget az eseményindító engedélyezéséhez, ha azt szeretné, hogy a build fusson, amikor valaki kódot keres.

Batch-módosítások

Jelölje be ezt a jelölőnégyzetet, ha sok csapattag gyakran tölt fel módosításokat, és csökkenteni szeretné a futó buildek számát. Ha ezt a lehetőséget választja, egy build futtatásakor a rendszer megvárja, amíg a futtatás befejeződik, majd a még nem létrehozott módosítások egy újabb futtatását várólistára állítja.

A módosításokat kötegelheti és együtt is összeállíthatja.

Feljegyzés

Ha többfázisú YAML-folyamattal kötegelést használ, akkor a futtatásnak el kell érnie egy terminálállapotot, mielőtt a következő elindulhat. Ez gyakran nem kívánatos, mivel egy többfázisú folyamat jóváhagyásokon és hosszú ideig futó üzembe helyezési fázisokon megy keresztül. Ezekben az esetekben javasoljuk, hogy kövesse az alábbi megoldások egyikét:

• ne használjon kötegelést
• a folyamat felosztása két különálló folyamatra – egy a CI-hez és egy CD-re
• állítsa be a megfelelő feltételeket a szakaszokon a kihagyáshoz és a futtatás gyors leállításához

Ágszűrők

Megadhatja azokat az ágakat, ahol a buildeket aktiválni szeretné. Ha helyettesítő karaktereket szeretne használni, írja be az ág specifikációját (például features/modules/*), majd nyomja le az Enter billentyűt.

Elérésiút-szűrők

Ha a Git-adattár az Azure Reposban vagy a TFS-ben található, elérésiút-szűrőket is megadhat a buildet aktiválni kívánt fájlok számának csökkentése érdekében.

Tippek:

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

Példa

Például azt szeretné, hogy a buildet a funkcióágak változásai main aktiválják, de nem az összeset. Azt sem szeretné, hogy a buildeket az eszközök mappájában lévő fájlok módosítása aktiválja.

Ci kihagyása egyéni véglegesíté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 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 azt okozzák, hogy a folyamat akkor fut, amikor egy lekéréses kérelmet az egyik megadott célággal nyitnak meg, vagy amikor frissítéseket végeznek egy ilyen lekéréses kérelemen.

YAML

Ágak

A lekéréses kérelmek érvényesítésekor megadhatja a célágakat. Például a célként megadott main lekéréses kérelmek érvényesítéséhez használhatja releases/*az alábbi pr eseményindítót.

pr:
- main
- releases/*

Ez a konfiguráció egy új futtatás indítását indítja el az új lekéréses kérelem első létrehozásakor, majd a lekéréses kérelem minden frissítését követően.

Megadhatja az ág teljes nevét (például main) vagy helyettesítő karaktert (például releases/*).

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.

A GitHub egy lekéréses kérelem létrehozásakor létrehoz egy új hiv-t . A ref egy egyesítési véglegesítésre mutat, amely a lekéréses kérelem forrás- és célágai közötti egyesített kód. A PR-érvényesítési folyamat létrehozza azt a véglegesítést, amelyre ez a ref mutat. Ez azt jelenti, hogy a folyamat futtatásához használt YAML-fájl a forrás és a célág egyesítését is jelenti. Ennek eredményeképpen a lekéréses kérelem forráságában lévő YAML-fájlban végzett módosítások felülírhatják a célágBAN lévő YAML-fájl által meghatározott viselkedést.

Ha a YAML-fájlban nem pr jelennek meg eseményindítók, a lekéréses kérelmek érvényesítése automatikusan engedélyezve lesz az összes ág esetében, mintha a következő pr eseményindítót írta volna. Ez a konfiguráció létrehoz egy buildet a lekéréses kérelmek létrehozásakor, és amikor véglegesítések kerülnek az aktív lekéréses kérelmek forráságába.

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

Fontos

Ha az ágak egy részhalmazával rendelkező eseményindítót pr ad meg, a folyamat csak akkor aktiválódik, ha a rendszer frissítéseket küld az adott ágakba.

Összetettebb eseményindítók esetén, amelyeknek ki kell zárniuk bizonyos ágakat, a teljes szintaxist kell használnia az alábbi példában látható módon. Ebben a példában a lekéréses kérelmek ellenőrzik, hogy a cél main vagy releases/* az ág releases/old* ki van zárva.

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

Elérési utak

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

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

Tippek:

• Az Azure Pipelines semleges állapotot ad vissza a GitHubhoz, amikor úgy dönt, hogy nem futtat érvényesítési buildet egy elérési út kizárási szabálya miatt. Ez egyértelmű irányt ad a GitHubnak, amely azt jelzi, hogy az Azure Pipelines befejezte a feldolgozást. További információ: Post neutral status to GitHub when a build is skipped.
• A helyettesítő kártyák mostantól elérésiút-szűrőkkel is támogatottak.
• 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).
• Az Azure Pipelines semleges állapotot ad vissza a GitHubhoz, amikor úgy dönt, hogy nem futtat érvényesítési buildet egy elérési út kizárási szabálya miatt.

Több pr-frissítés

Megadhatja, hogy a lekéréses kérelem további frissítései megszakítják-e ugyanahhoz a lekéréses kérelemhez tartozó folyamatban lévő érvényesítési futtatásokat. Az alapértelmezett érték true.

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

Pr-ellenőrzés piszkozata

Alapértelmezés szerint a lekéréses kérelem aktiválja a piszkozat lekéréses kérelmeket és a felülvizsgálatra kész lekéréses kérelmeket. A lekéréses kérelmek lekéréses kérelmeinek letiltásához állítsa a tulajdonságot a drafts következőre false: .

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

Leiratkozás a lekéréses kérelem érvényesítéséről

A lekéréses kérelmek érvényesítését teljes egészében kikapcsolhatja a pr: nonebeállítás megadásával.

# no PR triggers
pr: none

További információ: PR-eseményindító a YAML-sémában.

Feljegyzés

Ha az pr eseményindító nem aktiválódik, kövesse a gyakori kérdések hibaelhárítási lépéseit.

Klasszikus

Jelölje be a Lekéréses kérelem érvényesítési eseményindítót, és jelölje be a Lekéréses kérelmek érvényesítésének engedélyezése jelölőnégyzetet a lekéréses kérelmek buildjeinek engedélyezéséhez.

Megadhatja a belefoglalni és kizárni kívánt ágakat. Válasszon egy ágnevet a legördülő menüből, és válassza a Belefoglalás vagy kizárás lehetőséget. A belefoglalt ágak esetében a rendszer minden leküldéskor elindít egy buildet az adott ágat megcélzó lekéréses kérelemhez.

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 lekéréses kérelem célágán pr-eseményindítóval rendelkező 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, ha az egyesítési véglegesítés üzenete vagy leírása nem tartalmazza [skip ci] (vagy annak egyik változatát).

Védett ágak

Futtathat egy érvényesítési buildet minden olyan véglegesítési vagy lekéréses kérelemmel, amely egy ágat céloz meg, és még azt is megakadályozhatja, hogy a lekéréses kérelmek egyesülnek, amíg az érvényesítési build sikeres lesz.

A GitHub-adattár kötelező érvényesítési buildjeinek konfigurálásához a tulajdonosának, a rendszergazdai szerepkörrel együttműködőnek vagy az Írás szerepkörrel rendelkező GitHub-szervezet tagjának kell lennie.

1. Először hozzon létre egy folyamatot az adattárhoz, és hozza létre legalább egyszer, hogy az állapota közzé legyen téve a GitHubon, ezáltal a GitHub értesüljön a folyamat nevéről.

2. Ezután kövesse a GitHub dokumentációját a védett ágak adattár beállításaiban való konfigurálásához.

   Az állapot-ellenőrzéshez válassza ki a folyamat nevét az Állapotellenőrzések listában.

   

Fontos

Ha a folyamat nem jelenik meg ebben a listában, győződjön meg a következőkről:

• GitHub-alkalmazáshitelesítést használ
• A folyamat legalább egyszer futott az elmúlt héten

Külső forrásokból származó hozzájárulások

Ha a GitHub-adattár nyílt forráskód, nyilvánossá teheti az Azure DevOps-projektet, hogy bejelentkezés nélkül bárki megtekinthesse a folyamat builderedményeit, naplóit és teszteredményeit. Amikor a szervezeten kívüli felhasználók elágazzák az adattárat, és lekéréses kérelmeket küldenek, megtekinthetik azoknak a buildeknek az állapotát, amelyek automatikusan ellenőrzik ezeket a lekéréses kérelmeket.

A külső forrásokból származó hozzájárulások elfogadásakor vegye figyelembe a következő szempontokat, amikor az Azure Pipelinest nyilvános projektben használja.

• Hozzáférési korlátozások
• Az elágazásokból származó hozzájárulások ellenőrzése
• Fontos biztonsági szempontok

Hozzáférési korlátozások

Vegye figyelembe a következő hozzáférési korlátozásokat, amikor folyamatokat futtat az Azure DevOps nyilvános projektjeiben:

• Titkos kulcsok: Alapértelmezés szerint a folyamathoz társított titkos kulcsok nem érhetők el az elágazások kérésének érvényesítéséhez. Lásd: Elágazásokból származó hozzájárulások ellenőrzése.
• Projektközi hozzáférés: Egy Nyilvános Azure DevOps-projekt összes folyamata a projektre korlátozott hozzáférési jogkivonattal fut. A nyilvános projektekben lévő folyamatok csak a projekten belül férhetnek hozzá az erőforrásokhoz, például a buildelési összetevőkhöz vagy a tesztelési eredményekhez, az Azure DevOps-szervezet más projektjeiben nem.
• Azure Artifacts-csomagok: Ha a folyamatoknak hozzá kell férniük az Azure Artifacts csomagjaihoz, explicit módon engedélyt kell adnia a Project Build Service-fióknak a csomagcsatornák eléréséhez.

Elágazásokból származó hozzájárulások

Fontos

Ezek a beállítások befolyásolják a folyamat biztonságát.

Amikor létrehoz egy folyamatot, az automatikusan aktiválódik az adattár elágazásaiból érkező lekéréses kérelmek esetén. Ezt a viselkedést módosíthatja, gondosan mérlegelve, hogy ez hogyan befolyásolja a biztonságot. A viselkedés engedélyezéséhez vagy letiltásához:

1. Nyissa meg az Azure DevOps-projektet. Válassza a Folyamatok lehetőséget, keresse meg a folyamatot, és válassza a Szerkesztés lehetőséget.
2. Válassza az Eseményindítók lapot. A lekéréses kérelem eseményindítójának engedélyezése után engedélyezze vagy tiltsa le a buildelési lekéréses kérelmeket az adattár elágaztatásaiból jelölőnégyzetet.

A GitHub-folyamatok esetében alapértelmezés szerint a buildelési folyamathoz társított titkos kulcsok nem lesznek elérhetők az elágaztatások lekérésére irányuló kérésekhez. Ezek a titkos kódok alapértelmezés szerint engedélyezve vannak a GitHub Enterprise Server-folyamatokkal. Titkos kódok a következők:

• Biztonsági jogkivonat a GitHub-adattárhoz való hozzáféréssel.
• Ezek az elemek, ha a folyamat használja őket:
  • Szolgáltatáskapcsolat hitelesítő adatai
  • Fájlok a biztonságos fájltárból
  • Titkos kóddal jelölt változók létrehozása

Ha meg szeretné kerülni ezt az óvintézkedést a GitHub-folyamatokon, engedélyezze a Titkos kulcsok elérhetővé tétele az elágaztatások készítéséhez jelölőnégyzetet. Vegye figyelembe, hogy ez a beállítás milyen hatással van a biztonságra.

Feljegyzés

Ha engedélyezi az elágazás-buildek titkos kulcsokhoz való hozzáférését, az Azure Pipelines alapértelmezés szerint korlátozza az elágazás-buildekhez használt hozzáférési jogkivonatot. A nyitott erőforrásokhoz korlátozottabb hozzáféréssel rendelkezik, mint egy normál hozzáférési jogkivonat. Ha az elágazás-buildekhez ugyanazokat az engedélyeket szeretné adni, mint a normál buildek, engedélyezze, hogy az elágazás-buildek ugyanolyan engedélyekkel rendelkezzenek, mint a normál buildek beállítása.

További információ: Adattárvédelem – Elágazások.

Az elágaztatott GitHub-adattárakból származó, elágaztatott GitHub-adattárakból származó PRS-ek központilag definiálhatók az elágaztatott GitHub-adattárakból érkező lekéréses kérelmek korlátozásával. Szervezeti és projektszinten is elérhető. A következő lehetőségek közül választhat:

• Lekéréses kérelmek létrehozásának letiltása elágazott adattárakból
• Lekéréses kérelmek biztonságos összeállítása elágazott adattárakból
• Az elágazott tárházakból származó lekéréses kérelmek létrehozásának szabályainak testreszabása

A Sprint 229-től kezdve a folyamatok biztonságának javítása érdekében az Azure Pipelines már nem készít automatikusan lekéréses kérelmeket az elágaztatott GitHub-adattárakból. Az új projektek és szervezetek esetében az elágaztatott GitHub-adattárakból érkező lekéréses kérelmek korlátozásának alapértelmezett értéke az elágaztatott tárházakból érkező lekéréses kérelmek letiltása.

Ha az elágazott adattárak biztonságos buildelési kéréseit választja, az összes folyamat, szervezet vagy projekt egésze nem tudja elérhetővé tenni a titkos kulcsokat az elágazott adattárakból származó PRs-buildekhez, nem teheti meg, hogy ezek a buildek ugyanolyan engedélyekkel rendelkezzenek, mint a normál buildek, és egy PR-megjegyzésnek kell aktiválnia. A projektek továbbra is dönthetnek úgy, hogy nem engedélyezik a folyamatok számára az ilyen PRS-ek kiépítését.

Amikor a Testreszabás lehetőséget választja, meghatározhatja , hogyan korlátozhatja a folyamat beállításait. Gondoskodhat például arról, hogy minden folyamat megjegyzést igényeljen ahhoz, hogy egy elágaztatott GitHub-adattárból hozzon létre egy pr-t, ha a lekéréses kérelem nem csapattagok és nem közreműködők tulajdonában van. De dönthet úgy, hogy engedélyezi számukra, hogy titkos kulcsokat tegyenek elérhetővé az ilyen buildekhez. A projektek dönthetnek úgy, hogy nem engedélyezik a folyamatok számára az ilyen PRS-ek készítését, vagy biztonságosan építik fel őket, vagy még szigorúbb beállításokkal rendelkeznek, mint a szervezet szintjén megadottak.

A vezérlő ki van kapcsolva a meglévő szervezetek számára. 2023 szeptemberétől az új szervezetek alapértelmezés szerint be vannak kapcsolva az elágazott adattárakból származó lekéréses kérelmek biztonságos buildelésével.

Fontos biztonsági szempontok

A GitHub-felhasználók elágaztathatják az adattárat, módosíthatják, és létrehozhatnak egy lekéréses kérelmet, amely módosításokat javasol az adattárban. Ez a lekéréses kérelem rosszindulatú kódot tartalmazhat, amely az aktivált build részeként fut. Az ilyen kód a következő módokon okozhat kárt:

• Titkos kulcsok kiszivárgása a folyamatból. A kockázat csökkentése érdekében ne engedélyezze a Titkos kulcsok elérhetővé tétele elágazások készítéséhez jelölőnégyzetet, ha az adattár nyilvános, vagy nem megbízható felhasználók küldhetnek lekéréses kérelmeket, amelyek automatikusan aktiválják a buildeket. Ez a beállítás alapértelmezés szerint le van tiltva.

• Feltörheti az ügynököt futtató gépet, hogy kódokat vagy titkos kulcsokat lopjon el más folyamatokból. Ennek enyhítése:

  • A Microsoft által üzemeltetett ügynökkészlet használatával lekéréses kérelmeket hozhat létre az elágazásokból. A Microsoft által üzemeltetett ügynökgépek azonnal törlődnek a buildelés befejezése után, így nincs maradandó hatásuk, ha veszélybe kerülnek.

  • Ha saját üzemeltetésű ügynököt kell használnia, ne tároljon titkos kulcsokat, és ne végezzen más olyan buildeket és kiadásokat, amelyek titkos kódokat használnak ugyanazon az ügynökön, kivéve, ha az adattár privát, és megbízik a lekéréses kérelmek létrehozóiban.

Megjegyzés-eseményindítók

Az adattár közreműködői megjegyzéseket fűzhetnek egy lekéréses kérelemhez egy folyamat manuális futtatásához. Íme néhány gyakori oka annak, hogy miért érdemes ezt megtennie:

• Előfordulhat, hogy nem szeretné automatikusan létrehozni az ismeretlen felhasználóktól érkező lekéréses kérelmeket, amíg a módosításokat nem lehet áttekinteni. Azt szeretné, hogy az egyik csapattag először tekintse át a kódot, majd futtassa a folyamatot. Ezt gyakran használják biztonsági intézkedésként az elágazott adattárakból származó kód létrehozásakor.
• Érdemes lehet futtatni egy opcionális tesztcsomagot vagy egy további ellenőrzési buildet.

A megjegyzés-eseményindítók engedélyezéséhez kövesse az alábbi két lépést:

1. Engedélyezze a lekéréses kérelmek eseményindítóit a folyamathoz, és győződjön meg arról, hogy nem zárta ki a célágat.
2. Az Azure Pipelines webes portálon szerkessze a folyamatot, és válassza a További műveletek, triggerek lehetőséget. Ezután a Lekéréses kérelmek érvényesítése területen engedélyezze a csapattag megjegyzésének megkövetelését a lekéréses kérelem létrehozása előtt.
   • A lekéréses kérelmek létrehozása előtt válassza az Összes lekéréses kérelemnél, ha egy csapattag megjegyzését szeretné megkövetelni. Ezzel a munkafolyamattal a csapattag áttekinti a lekéréses kérelmet, és egy megjegyzéssel aktiválja a buildet, miután a lekéréses kérelem biztonságosnak minősül.
   • Válassza a Csak a nem csapattagok lekéréses kérelmeinél, ha csak akkor szeretné megkövetelni a csoporttag megjegyzését, ha egy nem csapattag kér lekéréses kérelmet. Ebben a munkafolyamatban a csapattagoknak nincs szükségük egy másodlagos csoporttag áttekintésére a build indításához.

Ezzel a két módosítással a lekéréses kérelmek érvényesítési buildje nem aktiválódik automatikusan, kivéve, ha a rendszer csak a nem csapattagok lekéréses kérelmeit választja ki, és a lekéréses kérelmet egy csapattag hajtja végre. Csak az "Írás" engedéllyel rendelkező adattártulajdonosok és közreműködők indíthatják el a buildet a lekéréses kérelem /AzurePipelines run megjegyzésével./AzurePipelines run <pipeline-name>

Megjegyzésekben az alábbi parancsokat lehet kiadni az Azure Pipelinesnak:

Parancs	Eredmény
/AzurePipelines help	Az összes támogatott parancs súgójának megjelenítése.
/AzurePipelines help <command-name>	A megadott parancs súgójának megjelenítése.
/AzurePipelines run	Futtassa az adattárhoz társított összes folyamatot, amelyek eseményindítói nem zárják ki ezt a lekéréses kérelmet.
/AzurePipelines run <pipeline-name>	Futtassa a megadott folyamatot, hacsak az eseményindítói nem zárják ki ezt a lekéréses kérelmet.

Feljegyzés

A rövidség kedvéért megjegyzéseket /azp fűzhet ahelyett /AzurePipelines, hogy a .

Fontos

Ezekre a parancsokra adott válaszok csak akkor jelennek meg a lekéréses kérelmek megbeszélésében, ha a folyamat az Azure Pipelines GitHub-alkalmazást használja.

Lekéréses kérelem megjegyzés-eseményindítóinak hibaelhárítása

Ha rendelkezik a szükséges adattár-engedélyekkel, de a folyamatokat nem aktiválják a megjegyzések, győződjön meg arról, hogy a tagsága nyilvános az adattár szervezetében, vagy közvetlenül hozzáadhatja magát adattár-közreműködőként. A folyamatok csak akkor láthatják a magánszervezet tagjait, ha közvetlen közreműködők, vagy közvetlen közreműködői csoporthoz tartoznak. Itt módosíthatja a GitHub-szervezeti tagságot privátról nyilvánosra (a szervezet nevére cserélve Your-Organization ): https://github.com/orgs/Your-Organization/people.

Információs futtatások

Egy információs futtatás azt jelzi, hogy az Azure DevOps nem tudta lekérni egy YAML-folyamat forráskódját. A forráskód lekérése külső eseményekre, például leküldéses véglegesítésre válaszul történik. Belső eseményindítókra is reagálva történik, például annak ellenőrzése, hogy vannak-e kódmódosítások, és ütemezett futtatás indítása vagy sem. A forráskód lekérése több okból is meghiúsulhat, mivel a git-adattár szolgáltatója gyakran kéri a szabályozást. Az információs futtatás megléte nem feltétlenül jelenti azt, hogy az Azure DevOps futtatni fogja a folyamatot.

Az információs futtatás az alábbi képernyőképen láthatóhoz hasonlóan néz ki.

A következő attribútumok által futtatott információk felismerhetők:

• Az állapot: Canceled
• Az időtartam: < 1s
• A futtatás neve a következő szövegek egyikét tartalmazza:
  • 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.
• A futtatás neve általában azt a BitBucket/GitHub-hibát tartalmazza, amely miatt a YAML-folyamat betöltése meghiúsult
• Nincsenek fázisok / feladatok / lépések

További információ az információs futtatásokról.

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

YAML

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 mycustompath C:\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 path folyamat 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

Klasszikus

Ez a beállítás nem konfigurálható a klasszikus szerkesztőben. A forráskód ki lesz véve egy úgynevezett skönyvtárba, amely relatív $(Agent.BuildDirectory). Például: ha $(Agent.BuildDirectory) igen C:\agent\_work\1, akkor a forráskód ki lesz véve a programból C:\agent\_work\1\mycustompath.

Submodules

YAML

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

Klasszikus

Ha almodulokból szeretne fájlokat letölteni, konfigurálhatja az Almodulok beállítást a folyamatban lévő Források lekérése feladat tulajdonságaiból.

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 "<BASE64_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? Egy: 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.

YAML

A beállítást a fetchTags folyamat 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.

   

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

   

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

   

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.

Klasszikus

A szinkronizálási címkék beállítását a folyamatban lévő Források lekérése feladat tulajdonságaiból konfigurálhatja.

Alapértelmezett viselkedés

• A 2022 szeptemberében kiadott Azure DevOps sprint 209 kiadása előtt létrehozott meglévő folyamatok esetében a címkék szinkronizálásának alapértelmezett értéke ugyanaz marad, mint a szinkronizálási címkék beállításainak hozzáadása előtt meglévő viselkedés, azaztrue.
• Az Azure DevOps sprint 209-es kiadása után létrehozott új folyamatok esetében a címkék szinkronizálásának alapértelmezett értéke .false

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.

YAML

A beállítást a fetchDepth folyamat 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.

   

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

   

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.

   

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.

Klasszikus

A Shallow beolvasási beállítást a folyamatban lévő Források lekérése feladat tulajdonságaiból konfigurálhatja.

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.

YAML

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

Klasszikus

Válassza a Forráskontronizálás mellőzése beállítást a folyamatban lévő Források lekérése tevékenység tulajdonságai közül.

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.

YAML

A beállítást a clean folyamat 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.

Klasszikus

Válassza a Tiszta beállítást a folyamatban lévő Források lekérése tevékenység tulajdonságai közül, és válasszon az alábbi 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.

YAML

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.

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.

Klasszikus

A Címkeforrások beállítást a folyamatban lévő Források lekérése tevékenység tulajdonságaiból konfigurálhatja.

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.

Előre definiált változók

GitHub-adattár létrehozásakor az előre definiált változók többsége elérhető a feladatok számára. Mivel azonban az Azure Pipelines nem ismeri fel a GitHubon frissítést végző felhasználó identitását, a következő változók rendszeridentitásra vannak beállítva a felhasználó identitása helyett:

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

Állapotfrissítések

Az Azure Pipelines kétféle állapotot ad vissza a GitHubra – az alapállapotokat és a GitHub-ellenőrzőfuttatásokat. A GitHub-ellenőrzések funkció csak a GitHub Appsben érhető el.

A folyamatállapotok a GitHub felhasználói felületén különböző helyeken jelennek meg.

• A PRS-ek a PR-beszélgetések lapon jelennek meg.
• Az egyes véglegesítések akkor jelennek meg, ha a véglegesítési idő után az állapotjel fölé viszi az egérmutatót az adattár véglegesítések lapján.

PAT vagy OAuth GitHub-kapcsolatok

PAT- vagy OAuth GitHub-kapcsolatokat használó folyamatok esetén a rendszer az állapotokat a futtatást aktiváló véglegesítési/pr-fájlba küldi vissza. A GitHub állapot API-ja az ilyen frissítések közzétételére szolgál. Ezek az állapotok korlátozott információkat tartalmaznak: a folyamat állapota (sikertelen, sikeres), a buildelési folyamatra mutató hivatkozás URL-címe és az állapot rövid leírása.

A PAT- vagy OAuth GitHub-kapcsolatok állapotai csak futtatási szinten lesznek elküldve. Más szóval egyetlen állapot frissíthető egy teljes futtatásra. Ha több feladat is fut, nem tehet közzé külön állapotot az egyes feladatokhoz. Azonban több folyamat is közzétehet különálló állapotokat ugyanarra a véglegesítésre.

GitHub-ellenőrzések

Az Azure Pipelines GitHub-alkalmazással beállított folyamatok esetében az állapot gitHub-ellenőrzések formájában lesz közzétéve. A GitHub-ellenőrzések lehetővé teszik a folyamat állapotára és tesztelésére, a kódlefedettségre és a hibákra vonatkozó részletes információk küldését. A GitHub Checks API itt található.

A GitHub-alkalmazást használó összes folyamat esetében a rendszer a teljes futtatás és a futtatás minden egyes feladatának ellenőrzésére kifüggeszti a rendszer.

A GitHub három lehetőséget biztosít, ha egy vagy több futtatás ellenőrzése sikertelen egy lekéréses/véglegesítési műveletnél. Dönthet úgy, hogy "újrafuttatja" az egyes ellenőrzéseket, újrafuttat minden sikertelen ellenőrzést az adott lekéréses/véglegesítési kérelemen, vagy újrafuttathatja az összes ellenőrzést, függetlenül attól, hogy az eredetileg sikeres volt-e.

A Futtatás ellenőrzése név melletti "Újrafuttatás" hivatkozásra kattintva az Azure Pipelines újrapróbálkozza a futtatást létrehozó futtatást. Az eredményül kapott futtatás ugyanazzal a futtatási számmal fog rendelkezni, és a forráskód, a konfiguráció és a YAML-fájl ugyanazt a verzióját fogja használni, mint a kezdeti build. Csak azok a feladatok futnak újra, amelyek a kezdeti futtatás során meghiúsultak, és a függő alárendelt feladatok is újra futnak. A "Minden sikertelen ellenőrzés újrafuttatása" hivatkozásra való kattintásnak ugyanaz a hatása. Ez ugyanaz a viselkedés, mint amikor az Azure Pipelines felhasználói felületén az "Újrafuttatás" gombra kattint. A "Minden ellenőrzés újrafuttatása" gombra kattintva új futtatás jön létre egy új futtatási számmal, és a konfiguráció vagy a YAML-fájl módosításait fogja átvenni.

Korlátozások

• A legjobb teljesítmény érdekében legfeljebb 50 folyamatot ajánlunk egyetlen adattárban. Az elfogadható teljesítmény érdekében legfeljebb 100 folyamatot ajánlunk egyetlen adattárban. Az adattárba való leküldés feldolgozásához szükséges idő az adattárban lévő folyamatok számával együtt nő. Amikor leküldés történik egy adattárba, az Azure Pipelinesnak be kell töltenie az összes YAML-folyamatot az adattárban, hogy kiderítse, valamelyiknek futnia kell-e, és az egyes folyamatok betöltése teljesítménybeli büntetést von maga után. A teljesítményproblémák mellett, ha egy adattárban túl sok folyamat található, a GitHub oldalán szabályozáshoz vezethet, mivel az Azure Pipelines rövid idő alatt túl sok kérést intézhet.

• A kiterjesztések és sablonok használata a folyamatokban hatással van arra, hogy az Azure Pipelines milyen sebességgel küldi el a GitHub API-kéréseket, és szabályozáshoz vezethet a GitHub oldalán. A folyamat futtatása előtt az Azure Pipelinesnak létre kell hoznia a teljes YAML-kódot, ezért le kell kérnie az összes sablonfájlt.

• Az Azure Pipelines legfeljebb 2000 ágat tölt be egy adattárból a legördülő listákba az Azure DevOps Portalon, például a Manuális és ütemezett buildek alapértelmezett ágának kiválasztása ablakában, vagy amikor manuálisan futtat egy ágat.

  Ha nem látja a kívánt ágat a listában, írja be manuálisan a kívánt ág nevét a manuális és ütemezett buildek alapértelmezett ágába.

  Ha a három pontra kattint, és megnyitja az Ág kiválasztása párbeszédpanelt, és bezárja anélkül, hogy érvényes ágat választanál a legördülő listából, előfordulhat, hogy egy bizonyos beállításnak figyelmet kell fordítania, és ez a beállítás az Alapértelmezett ág alatt jelenik meg a manuális és ütemezett buildekhez. Az üzenet megkerüléséhez nyissa meg újra a folyamatot, és adja meg a nevet közvetlenül az Alapértelmezett ágban manuális és ütemezett buildek esetén.

GYIK

A GitHub-integrációval kapcsolatos problémák a következő kategóriákba sorolhatók:

• Kapcsolattípusok: Nem tudom, milyen kapcsolattípust használok a folyamat GitHubhoz való csatlakoztatásához.
• Sikertelen eseményindítók: A folyamat nem aktiválódik, amikor leküldök egy frissítést az adattárba.
• Sikertelen kivétel: A folyamat aktiválva van, de a kivételi lépésben meghiúsul.
• Helytelen verzió: A folyamat fut, de a forrás/YAML váratlan verzióját használja.
• Hiányzó állapotfrissítések: A GitHub-kiszolgálóim le vannak tiltva, mert az Azure Pipelines nem jelentett állapotfrissítést.

Kapcsolattípusok

Az eseményindítók hibaelhárításához honnan tudhatom meg, hogy milyen típusú GitHub-kapcsolatot használok a folyamatomhoz?

Az eseményindítókkal kapcsolatos problémák elhárítása nagyban függ a folyamatban használt GitHub-kapcsolat típusától. Kétféleképpen határozható meg a kapcsolat típusa – a GitHubról és az Azure Pipelinesból.

• GitHubról: Ha egy adattár be van állítva a GitHub-alkalmazás használatára, akkor a PRS és a véglegesítések állapota a Futtatás ellenőrzése lesz. Ha az adattárban az Azure Pipelines OAuth- vagy PAT-kapcsolatokkal van beállítva, az állapotok a "régi" állapotstílusok lesznek. Ha gyorsan meg szeretné állapítani, hogy az állapotok futtatások ellenőrzése vagy egyszerű állapotok-e, egy GitHub PR beszélgetés lapjának megtekintésével állapíthatja meg.

  • Ha a "Részletek" hivatkozás az Ellenőrzések lapra irányítja át, az egy futtatás ellenőrzése, és az adattár az alkalmazást használja.
  • Ha a "Részletek" hivatkozás átirányítja az Azure DevOps-folyamatra, akkor az állapot "régi stílus" állapotú, és az adattár nem használja az alkalmazást.

• Az Azure Pipelinesból: A kapcsolat típusát úgy is meghatározhatja, hogy megvizsgálja a folyamatot az Azure Pipelines felhasználói felületén. Nyissa meg a folyamat szerkesztőjének megnyitását. Válassza az Eseményindítók lehetőséget a folyamat klasszikus szerkesztőjének megnyitásához. Ezután válassza a YAML lapot, majd a Források lekérése lépést. Egy kapcsolattal engedélyezett szalagcím jelenik meg: a folyamat GitHubbal való integrálásához használt szolgáltatáskapcsolatot jelzi. A szolgáltatáskapcsolat neve hivatkozás. Válassza ki a szolgáltatáskapcsolat tulajdonságaihoz való navigáláshoz. A szolgáltatáskapcsolat tulajdonságai a használt kapcsolat típusát jelzik:

  • Az Azure Pipelines alkalmazás GitHub-alkalmazáskapcsolatot jelez
  • Az oauth OAuth-kapcsolatot jelez
  • A personalaccesstoken PAT-hitelesítést jelez

Hogyan váltson a folyamatomra, hogy az OAuth helyett GitHub-alkalmazást használjon?

A GitHub és az Azure Pipelines közötti ajánlott integráció az OAuth- vagy PAT-kapcsolat helyett egy GitHub-alkalmazás használata. A GitHub-alkalmazásra való váltáshoz kövesse az alábbi lépéseket:

1. Lépjen ide , és telepítse az alkalmazást az adattár GitHub-szervezetében.
2. A telepítés során a rendszer átirányítja az Azure DevOpsba egy Azure DevOps-szervezet és -projekt kiválasztásához. Válassza ki azt a szervezetet és projektet, amely tartalmazza az alkalmazást használni kívánt klasszikus buildelési folyamatot. Ez a választás társítja a GitHub-alkalmazás telepítését az Azure DevOps-szervezethez. Ha helytelenül dönt, ezen a lapon eltávolíthatja a GitHub-alkalmazást a GitHub-szervezetből, és újrakezdheti.
3. A következő megjelenő lapon nem kell új folyamatot létrehoznia.
4. A folyamat szerkesztéséhez nyissa meg a Folyamatok lapot (például https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build)jelölje ki a folyamatot, és kattintson a Szerkesztés gombra.
5. Ha ez egy YAML-folyamat, válassza az Eseményindítók menüt a klasszikus szerkesztő megnyitásához.
6. Válassza a "Források lekérése" lépést a folyamatban.
7. Az "Engedélyezett kapcsolat használatával" szöveggel ellátott zöld sávon válassza a "Módosítás" lehetőséget, és válassza ki azt a GitHub-alkalmazáskapcsolatot, amelynek a neve megegyezik azzal a GitHub-szervezettel, amelyben telepítette az alkalmazást.
8. Az eszköztáron válassza a "Mentés és üzenetsor", majd a "Mentés és üzenetsor" lehetőséget. Válassza ki a várólistára helyezett folyamatfuttatásra mutató hivatkozást, hogy biztosan sikeres legyen.
9. Hozzon létre (vagy zárjon be és nyisson meg újra) egy lekéréses kérelmet a GitHub-adattárban annak ellenőrzéséhez, hogy a build sikeresen várólistára került-e az "Ellenőrzések" szakaszban.

Miért nem jelenik meg egy GitHub-adattár az Azure Pipelinesban való választáshoz?

Az adattár hitelesítési típusától és tulajdonjogától függően adott engedélyekre van szükség.

• Ha a GitHub-alkalmazást használja, tekintse meg a GitHub-alkalmazás hitelesítését.
• Ha OAuthot használ, tekintse meg az OAuth-hitelesítést.
• Ha PAT-eket használ, tekintse meg a személyes hozzáférési jogkivonat (PAT) hitelesítését.

Amikor kiválasztok egy adattárat a folyamat létrehozása során, hibaüzenet jelenik meg: "Az adattár {repo-name} használatban van az Azure Pipelines GitHub alkalmazással egy másik Azure DevOps-szervezetben."

Ez azt jelenti, hogy az adattár már egy másik szervezetben lévő folyamathoz van társítva. Az adattárból származó CI- és PR-események nem működnek, mivel azok a másik szervezetnek lesznek kézbesítve. A folyamat létrehozása előtt az alábbi lépéseket kell elvégeznie a másik szervezet leképezésének eltávolításához.

1. Nyisson meg egy lekéréses kérelmet a GitHub-adattárban, és tegye a megjegyzést /azp where. Ez a jelentés azt az Azure DevOps-szervezetet jelenti, amellyel az adattár le van képezve.

2. A leképezés módosításához távolítsa el az alkalmazást a GitHub-szervezetből, és telepítse újra. Az újratelepítés során mindenképpen válassza ki a megfelelő szervezetet, amikor átirányítja az Azure DevOpsba.

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.

  

  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.

  

• A GitHub alkalmazáskapcsolatot használja a folyamat GitHubhoz való csatlakoztatásához? A kapcsolat típusának meghatározásához tekintse meg a kapcsolattípusokat . Ha GitHub-alkalmazáskapcsolatot használ, kövesse az alábbi lépéseket:

  • Megfelelően van beállítva a leképezés a GitHub és az Azure DevOps között? Nyisson meg egy lekéréses kérelmet a GitHub-adattárban, és tegye a megjegyzést /azp where. Ez a jelentés azt az Azure DevOps-szervezetet jelenti, amellyel az adattár le van képezve.

    • Ha nincs olyan szervezet, amely az alkalmazással hozza létre ezt az adattárat, nyissa meg https://github.com/<org_name>/<repo_name>/settings/installations és fejezze be az alkalmazás konfigurációját.

    • Ha egy másik Azure DevOps-szervezetről van szó, akkor valaki már létrehozott egy folyamatot ehhez az adattárhoz egy másik szervezetben. Jelenleg az a korlátozás van érvényben, hogy csak egyetlen DevOps-szervezethez rendelhetjük le a GitHub-adattárat. Csak az első Azure DevOps-szervezet folyamatait lehet automatikusan aktiválni. A leképezés módosításához távolítsa el az alkalmazást a GitHub-szervezetből, és telepítse újra. Az újratelepítés során mindenképpen válassza ki a megfelelő szervezetet, amikor átirányítja az Azure DevOpsba.

• OAuth vagy PAT használatával csatlakoztatja a folyamatot a GitHubhoz? A kapcsolat típusának meghatározásához tekintse meg a kapcsolattípusokat . Ha GitHub-kapcsolatot használ, kövesse az alábbi lépéseket:

  1. Az OAuth- és PAT-kapcsolatok webhookokra támaszkodnak, hogy frissítéseket közöljenek az Azure Pipelinesszal. A GitHubon navigáljon az adattár beállításaihoz, majd a Webhookokhoz. Ellenőrizze, hogy léteznek-e webhookok. Általában három webhookot kell látnia : leküldés, pull_request és issue_comment. Ha nem, akkor újra létre kell hoznia a szolgáltatáskapcsolatot, és frissítenie kell a folyamatot az új szolgáltatáskapcsolat használatához.

  2. Jelölje ki az egyes webhookokat a GitHubon, és ellenőrizze, hogy a felhasználó véglegesítésének megfelelő hasznos adat létezik-e, és sikeresen elküldve lett-e az Azure DevOpsnak. Itt hibaüzenet jelenhet meg, ha az esemény nem küldhető el az Azure DevOpsnak.

• Az Azure DevOpsból érkező forgalmat a GitHub szabályozhatja. Amikor az Azure Pipelines értesítést kap a GitHubról, megpróbál kapcsolatba lépni a GitHubbal, és további információkat kér le az adattárról és a YAML-fájlról. Ha nagy számú frissítéssel és lekéréses kéréssel rendelkező adattárral rendelkezik, a hívás az ilyen szabályozás miatt meghiúsulhat. Ebben az esetben ellenőrizze, hogy csökkentheti-e a buildek gyakoriságát kötegelés vagy szigorúbb elérésiút-/ágszűrők használatával.

• A folyamat szüneteltetve van vagy le van tiltva? Nyissa meg a folyamat szerkesztőjében, majd válassza a Beállítások lehetőséget 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, majd kövesse az alá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? A késést á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. Az alábbiakban néhány okot talál a késés okaira:

  • Szolgáltatáskimaradást tapasztalunk 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.
  • Az adattár túl sok YAML-folyamatot tartalmaz. A legjobb teljesítmény érdekében legfeljebb 50 folyamatot ajánlunk egyetlen adattárban. Az elfogadható teljesítmény érdekében legfeljebb 100 folyamatot ajánlunk egyetlen adattárban. Minél több folyamat van, annál lassabb a leküldés feldolgozása az adattárba. Amikor leküldés történik egy adattárba, az Azure Pipelinesnak be kell töltenie az összes YAML-folyamatot az adattárba, hogy kiderítse, valamelyiknek futnia kell-e, és minden új folyamat teljesítménybeli büntetést von maga után.

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.

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: Repository not found.
fatal: repository <repo> not found

Ezt a GitHub leállása okozhatja. Próbálja meg elérni az adattárat a GitHubon, és győződjön meg arról, hogy képes rá.

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.

Hiányzó állapotfrissítések

A GitHubon a lekéréses kérelem le van tiltva, mivel az Azure Pipelines nem frissítette az állapotot.

Ez átmeneti hiba lehet, amely miatt az Azure DevOps nem tud kommunikálni a GitHubbal. Ha a GitHub-alkalmazást használja, próbálkozzon újra a GitHub beadása során. Vagy készítsen egy aprólékos frissítést a lekéréses kérelemre, hogy meg lehessen-e oldani a problémát.

Kapcsolódó cikkek

• Ütemezett triggerek
• Folyamatbefejező triggerek