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ő folyamatlétrehozása 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 szervezetekből és felhasználói fiókokból áll, amelyek adattárakattartalmaznak. Lásd GitHub dokumentációját.

Az Azure DevOps struktúrája szervezetekből áll, amelyek projektekettartalmaznak. Lásd: Szervezeti struktúra megtervezése.

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

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

-ra leképezett GitHub-struktúra

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. Olyan URL-cím fog rendelkezni, mint https://dev.azure.com/your-organization.
2. A DevOps-szervezetben hozzon létre az adattárakról elnevezett projekteket. Olyan URL-címekkel rendelkeznek, mint 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éldául:

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 https://github.com/orgs/your-organization/people találhatók (cserélje le your-organization).

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

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 tagja
Számlázási vezető	A Project Collection Administrators tagja
Tag	A Project Collection Valid Userstagja. 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 Create new projects engedélyét 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 https://dev.azure.com/your-organization/_settings/security találhatók (cserélje le your-organization).

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 tagja

GitHub-adattár engedélyei

A GitHub-adattár engedélyei https://github.com/your-organization/your-repository/settings/collaboration találhatók (cserélje le your-organization és your-repository).

A DevOps-projektengedélyek a https://dev.azure.com/your-organization/your-project/_settings/security találhatók (cserélje le 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ű
Admin	A Project Administrators tagja
Ír	A Contributors tagja
Olvas	A Readers tagja

Ha a GitHub-adattár engedélyt ad a csapatoknak, létrehozhat egyező csapatokat az Azure DevOps-projektbeállítások Teams 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ágilehetőséget.
4. Válassza Hozzáadás... egy adott felhasználó, csoport 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. A YAML-fájl tárházát self adattárnak nevezzük. 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 több-adattárbeli pénztáricímű témakörben talál.

klasszikus

Új folyamatot úgy hozhat létre, hogy először kiválasztja GitHub- adattártípushoz, majd az egyik tárházat, 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ési típus	A folyamatok a következő használatával futnak:	A GitHub-ellenőrzések
1. GitHub App	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 ajánlott hitelesítési típus a folyamatos integrációs folyamatokhoz. 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 GitHub Checks használatával jeleníti meg 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. Ha azonban az alkalmazás minden adattárhoz telepítve van, az alkalmazás által használt jogkivonat az összes adattárhoz, beleértve a privát adattárakat is. Biztonsági okokból javasoljuk, hogy szervezeti szinten különítse el a magán- és nyilvános adattárakat. Ez azt jelenti, hogy csak magánadattárak nélküli nyilvános projektekhez rendelkezik dedikált szervezettel. Ha valamilyen okból nyilvános és privát adattárakra van szükség ugyanabban a szervezetben, ahelyett, hogy minden adattárhoz hozzáférést használnál, explicit módon válassza ki azokat az adattárakat, amelyekhez az alkalmazásnak hozzáféréssel kell rendelkeznie. Ez több munkát igényel a rendszergazdák számára, de jobb biztonságkezelést biztosít.

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árlistában 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

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 a folyamat létrehozásakor az adattárak listája alatt. Ezután válassza engedélyezése 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árlistában 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 > Szolgáltatáskapcsolatok > Új szolgáltatáskapcsolat > GitHub > Engedélyezés területen végezhető el. Adjon hozzáférést az Azure Pipelinesnak az adattárakhoz az "Engedélyek" területen, itt.

• 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 > Szolgáltatáskapcsolatok > Új szolgáltatáskapcsolat > GitHub > Engedélyezés területen 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, itt. 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 > Szolgáltatáskapcsolatok > Új szolgáltatáskapcsolat > GitHub > Engedélyezés területen végezhető el. Adjon hozzáférést az Azure Pipelinesnak a szervezet számára a "Szervezeti hozzáférés" területen, itt. 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 > Szolgáltatáskapcsolatok > Új szolgáltatáskapcsolat > GitHub > Engedélyezés területen végezhető el. A szervezet tulajdonosának hozzáférést kell adnia az Azure Pipelines számára a szervezet számára a "Szervezeti hozzáférés" területen, itt. 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 visszavonja és megakadályozza a további használatot, látogasson el OAuth Apps a GitHub-beállítások között. Azt is törölheti a GitHub szolgáltatáskapcsolatok listájából, az Azure DevOps-projekt beállításai között.

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

PAT- hatékonyan megegyeznek az OAuth-zal, de lehetővé teszik az Azure Pipelines számára biztosított engedélyek szabályozását. 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 Személyes hozzáférési jogkivonatok a GitHub beállításai között. A szükséges engedélyek a következők: repo, admin:repo_hook, read: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árlistában 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ökhöz Személyes hozzáférési jogkivonatok: repo, admin:repo_hook, read:userés user:email.

• Ha az adattár valaki más személyes GitHub-fiókjában található, a PAT-nak rendelkeznie kell a szükséges hozzáférési hatókörökhöz Személyes hozzáférési jogkivonatok: 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: repo, admin:repo_hook, read:userés user:emailalatt. 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 Személyes hozzáférési jogkivonatok: repo, admin:repo_hook, read:userés user:emailalatt. 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 Személyes hozzáférési jogkivonatokat a GitHub beállításai között. Azt is törölheti a GitHub szolgáltatáskapcsolatok listájából, az Azure DevOps-projekt beállításai között.

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 ci-eseményindítóval vannak konfigurálva az összes ágon, kivéve, ha engedélyezve van a Azure DevOps sprint 227-es-ben bevezetett Implicit YAML CI-eseményindító beállítása. A A vélelmezett YAML CI-eseményindító letiltása beállítás a szervezet szintjén vagy a projekt szintjén konfigurálható. Ha a Letiltja a vélelmezett YAML CI-eseményindítót, beállítás engedélyezve van, a YAML-folyamatok CI-eseményindítói nem lesznek engedélyezve, ha a YAML-folyamatnak nincs trigger szakasza. Alapértelmezés szerint a A hallgatólagos 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 lásd helyettesítő karakterek.

Jegyzet

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

Jegyzet

Ha sablonokat YAML-fájlok létrehozásához, 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 exclude vagy batchhasználó összetettebb eseményindítók esetében 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 a módosítást main vagy bármely kiadási ágba küldi. Ez azonban nem aktiválódik, ha módosítás történik egy kiadási ágon, amely oldkezdődik.

Ha include záradék nélkül ad meg exclude záradékot, az egyenértékű a include záradékban szereplő * megadásával.

A branches listák ágneveinek 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 a A vélelmezett YAML CI-eseményindító letiltása beállítás nincs engedélyezve, az alapértelmezett érték a következő:

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 a batchtrueértékre állítja, amikor 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

Jegyzet

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 egy leküldéses Amain a fenti folyamat futtatását okozta. Amíg a folyamat fut, további leküldések B és C kerülnek 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.

Jegyzet

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.

Görbék

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, hogy az útvonalszűrővel együtt az összes ágra szűrjön.

Az elérésiút-szűrők támogatják a helyettesítő kártyákat. Felvehet például minden olyan elérési utat, amely megfelel src/app/**/myapp*. Az elérésiút-szűrők megadásakor használhat helyettesítő karaktereket (**, *vagy ?).

• 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 /tools, akkor /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 változók nem használhatók, 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

Amellett, hogy az előző szakaszban ismertetett címkéket adja meg az branches listákban, közvetlenül megadhatja a belefoglalandó vagy kizárandó 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: nonemegadá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

Válassza a Folyamatos integrációs engedélyezése a Eseményindítók lapon az eseményindító engedélyezéséhez, ha azt szeretné, hogy a build fusson, amikor valaki bejelentkezik a kódba.

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.

Jegyzet

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 /tools, akkor /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 az main változásai aktiválják, és a legtöbb, de nem az összes funkcióágban. 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 a [skip ci] az üzenetben vagy a leküldés részét képező véglegesítések leírásában, é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 Build.Reasonrendszerváltozóval teheti 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 frissítést küld a docs mappába, egy másikat pedig az alkalmazás kódjába való frissítéskor. 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 egyezzen, és ? egyetlen karakternek feleljen meg.

• Ha egy YAML-folyamatban * indítja el a mintát, a mintát idézőjelekbe kell csomagolnia, 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 ?.
  • Az Azure DevOps Server 2020-as és újabb operációs rendszerében előfordulhat, hogy a * szerepel a végleges karakterként, de nem tesz mást, mint a címtárnév önmagában történő megadása. Előfordulhat, hogy nem* szerepeltetni egy útvonalszűrő közepén, és nem használhatja a ?.

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. A main és releases/*megcélzott lekéréses kérelmek érvényesítéséhez például az alábbi pr eseményindítót használhatja.

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

Jegyzet

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

Jegyzet

Ha sablonokat YAML-fájlok létrehozásához, 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 létrehoz egy új hiv a lekéréses kérelem létrehozásakor. A ref egy egyesítési véglegesítésimutat, 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, amelyet 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 jelennek meg pr 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 egy pr eseményindítót ad meg az ágak egy részhalmazával, 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/* és az ág releases/old* ki van zárva.

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

Görbék

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

# 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ó: A GitHub semleges állapotának közzététele a build kihagyásakor.
• A helyettesítő kártyákat mostantólelérésiút-szűrők támogatják.
• 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 /tools, akkor /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 változók nem használhatók, 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 a 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 drafts tulajdonságot 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: nonemegadásával.

# no PR triggers
pr: none

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

Jegyzet

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

klasszikus

Jelölje be a Lekéréses kérelmek é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ása 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 egyesítési véglegesítési (a lekéréses kérelem forrás- és célágai közötti egyesített kód) futnak, függetlenül attól, hogy vannak-e leküldéses véglegesítések, amelyek üzenetei vagy leírásai [skip ci] (vagy annak bármely változata) tartalmaznak.
• A leküldéses kérelem forráságának módosítása által aktivált folyamatok, ha nem található leküldéses véglegesítés, amelynek üzenetei vagy leírásai [skip ci] (vagy annak bármely változatát) tartalmaznak. Ha legalább egy leküldéses véglegesítés [skip ci]tartalmaz, 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 tartalmaz [skip ci] (vagy annak bármely változata).

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 konfigurálásához az adattár beállításai között.

   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ési
• 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 bárki bejelentkezés nélkül 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
• 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ások hozzájárulásainak ellenőrzése.
• Projektközi hozzáférés: 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 Folyamatoklehetőséget, keresse meg a folyamatot, és válassza a Szerkesztéslehetőséget.
2. Válassza az Triggerek lapot. A lekéréses kérelem eseményindítójánakengedélyezése után engedélyezze vagy tiltsa le a Lekéréses kérelmek létrehozása 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áskapcsolati hitelesítő adatai
  • A biztonságos fájltárból származó fájlok
  • Titkos megjelö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 elágaztatások jelölőnégyzetet. Vegye figyelembe, hogy ez a beállítás milyen hatással van a biztonságra.

Jegyzet

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 a Az elágazás készítése buildek ugyanolyan engedélyekkel rendelkezzenek, mint a normál buildek beállítás.

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

Az 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, vezérléssel. 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 229kezdve a folyamatok biztonságának javítása érdekében Az Azure Pipelines többé nem készít automatikusan lekéréses kérelmeket az elágaztatott GitHub-adattárakból. Új projektek és szervezetek esetében a Az elágaztatott GitHub-adattárakból érkező lekéréses kérelmek korlátozásának alapértelmezett értéke beállítás Az elágaztatott tárházakból érkező lekéréses kérelmek letiltása.

Ha az elágazott adattárakból biztonságosan összeállítható lekéréses kérelmeket választja, az összes folyamat, szervezet vagy projektszintű, nem elérhetővé tenni titkos kulcsokat az elágazott adattárakból származó PRs-buildekhez, nem, hogy ezek a buildek a normál buildekkel megegyező engedélyekkel rendelkezzenek, és pr-megjegyzéssel kell aktiválni. 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.

Ha a Testreszabás lehetőséget választja, meghatározhatja, hogyan korlátozhatja a folyamatbeállításokat. 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 ami a szervezet szintjén meg van adva.

A vezérlő ki van kapcsolva a meglévő szervezetek számára. 2023 szeptemberétől az új szervezetek alapértelmezés szerintbiztonságosan építenek lekéréses kérelmeket az elágazott adattárakból, be vannak kapcsolva.

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 a 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 el más olyan buildeket és kiadásokat, amelyek titkos kulcsokat 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 webportálon szerkessze a folyamatot, és válassza a További műveletek, Triggereklehetőséget. Ezután a Lekéréses kérelmek érvényesítésiterületen engedélyezze a Csoporttag megjegyzésének megkövetelése a lekéréses kérelemlétrehozása előtt.
   • Válassza a Az összes lekéréses kérelemnél a csapattag megjegyzésének megköveteléséhez a lekéréses kérelem létrehozása előtt. 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 Csak a nem csapattagok lekéréses kérelmeinél a csoporttag megjegyzésének megköveteléséhez csak akkor, 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 Csak a nem csapattagok által küldött lekéréses kérelmekre van kiválasztva, és a lekéréses kérelmet egy csapattag hajtja végre. A buildet csak az "Írás" engedéllyel rendelkező adattártulajdonosok és közreműködők indíthatják el, ha megjegyzést fűznek a lekéréses kérelemhez /AzurePipelines run vagy /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.

Jegyzet

A rövidség kedvéért /AzurePipelineshelyett /azp megjegyzéseket fűzhet.

Fontos

Az 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áshaszná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 adja hozzá 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 (Your-Organization lecserélheti a szervezet nevére): 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ó információs futtatásokról.

Pénztár

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.

Jegyzet

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, kizárhatja a beépített kivételt checkout: none, majd egy szkriptfeladattal elvégezheti 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 System.PreferGitFromPathtrue. 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 snevű könyvtárba. YAML-folyamatok esetén ezt módosíthatja egy pathcheckout megadásával. A megadott elérési út a $(Agent.BuildDirectory). Ha például a kivételi útvonal értéke mycustompath, és $(Agent.BuildDirectory)C:\agent\_work\1, akkor a forráskód ki lesz véve a C:\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 pathhasználatával, az egyes adattárak az adattárról elnevezett s almappájába kerülnek. Ha például két, tools és codenevű adattárat vesz fel, a forráskód ki lesz véve C:\agent\_work\1\s\tools és 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 az $(Agent.BuildDirectory)fölötti könyvtárszinteket fel lehessen lépni, ezért a path\..\anotherpath érvényes kivételi útvonalat (például C:\agent\_work\1\anotherpath) eredményez, de a ..\invalidpath érték nem lesz (például C:\agent\_work\invalidpath).

A path beállítást a 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 snevű könyvtárba, amely $(Agent.BuildDirectory). Ha például $(Agent.BuildDirectory)C:\agent\_work\1, akkor a forráskód ki lesz véve a C:\agent\_work\1\mycustompath.

Submodules

YAML-

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

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

A Almodulok beállítást a folyamat Források lekérése feladat tulajdonságaiból konfigurálhatja, ha fájlokat szeretne letölteni almodulokbó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éldául

    • Ez ki van véve: 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 beállítást, 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őtagot pat:. Ezután base64 kódolású 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.

Jegyzet

K: Miért nem használhatok Git hitelesítőadat-kezelőt az ügynökön?A: 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ő adatok kezelője kérheti, hogy az almodul frissítésekor adja meg újra a hitelesítő adatokat. 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 az --tags lehetőséget használja a Git-adattár tartalmának beolvasásakor. 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ő.

Az adattárak kivételekor a címkék szinkronizálása a YAML-ben konfigurálható a fetchTags tulajdonság beállításával, a felhasználói felületen pedig a Szinkronizálási címkék beállítás konfigurálásával.

YAML-

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

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ási címkék beállítással is konfigurálhatja.

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

   

2. Válassza YAML, Források lekéréselehetőséget.

   

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

   

Jegyzet

Ha a checkout lépésben explicit módon állítja be a fetchTags, ez 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ást a folyamat Források lekérése feladat tulajdonságaiból konfigurálhatja.

Alapértelmezett viselkedés

• A Azure DevOps sprint 2092022 szeptemberében megjelent kiadása előtt létrehozott meglévő folyamatok esetében a címkék szinkronizálásának alapértelmezett beállítása ugyanaz marad, mint a Szinkronizálási címkék beállításainak hozzáadása előtt, ami true.
• 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 false.

Jegyzet

Ha a checkout lépésben explicit módon állítja be a fetchTags, ez 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 git fetch --depth=neredményez. 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élyezve vannak a Shallow beolvasási , é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 a következő szakaszban leírtak szerint.

YAML-

A fetchDepth beállítást a 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 a folyamatbeállítások felhasználói felületén a Sekély mélység beállításával is konfigurálhatja.

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

   

2. Válassza YAML, Források lekéréselehetőséget.

   

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

   

Jegyzet

Ha a checkout lépésben explicit módon állítja be a fetchDepth, ez 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 Sekély beolvasás beállítást.

klasszikus

A Sekély beolvasás beállítást a folyamat 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.

Jegyzet

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 A források szinkronizálásának mellőzése beállítást a folyamat Kivétel lépésében konfigurálhatja a checkout: nonebeállításával.

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

klasszikus

Válassza a A források szinkronizálásának mellőzése beállítást a folyamat Források lekérése feladat tulajdonságai közül.

Jegyzet

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 feladat vagy eszköz Tiszta lehetőségé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.

Jegyzet

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 clean beállítást a 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 cleantrue a buildelési folyamat visszavonja a $(Build.SourcesDirectory)módosításait. 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 egy feladatworkspace beállítását.

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 a $(Build.BinariesDirectory). Vegye figyelembe, hogy a $(Build.ArtifactStagingDirectory) és a $(Common.TestResultsDirectory) minden build előtt törlődik és újra létrejön, 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.

• az összes: Törli és újra létrehozza a $(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 folyamat Források lekérése feladat 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 $(Build.SourcesDirectory)módosításait. 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 Források fenti lehetőség, valamint: Törli és újra létrehozza $(Build.BinariesDirectory). Vegye figyelembe, hogy a $(Build.ArtifactStagingDirectory) és a $(Common.TestResultsDirectory) minden build előtt törlődik és újra létrejön, függetlenül ezektől a beállításoktól.

• Források kö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.

• Az összes 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 klasszikus szerkesztőhöz a YAML-szerkesztő menüjében Triggerek választva érheti el.

A klasszikus szerkesztőben válassza YAML, 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 folyamat Források lekérése feladat tulajdonságaiból konfigurálhatja.

A 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.Variable a változók lapon.

A buildelési folyamat egy Git-címkévelcí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 az olyan változók, mint a $(Build.RequestedFor) és a $(Build.DefinitionName) tartalmazhatnak üres helyet. Ha az érték üres területet tartalmaz, a címke nem jön létre.

Miután a forrásokat címkézte a buildelési folyamat, a rendszer automatikusan hozzáad egy Git-ref 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 a előre definiált változók többsége érhető el 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

A PAT vagy OAuth- GitHub-kapcsolatokat használó folyamatok esetében a rendszer az állapotokat a futtatást aktiváló véglegesítési/pr-fájlba küldi vissza. A GitHub állapot API- 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áshasználatával 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 használata kiterjeszti a és -sablonokat tartalmaz egy folyamatban, ami hatással van arra, hogy az Azure Pipelines milyen sebességgel küldi el a GitHub API-kéréseket, és a GitHub oldalán szabályozáshoz vezethet. 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 az Azure DevOps Portal legördülő listáiba, például a Válassza ki az ág ablakot a Alapértelmezett ághoz manuális és ütemezett buildekhez beállításhoz, 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 ágnevet a Manuális és ütemezett buildek alapértelmezett ágába mezőbe.

  Ha a három pontra kattint, és megnyitja a Válassza ki az ágat párbeszédet, és zárja be anélkül, hogy érvényes ágat választ a legördülő listából, Egyes beállításoknak figyelmet kell fordítaniuk üzenetre és egy Ez a beállítás az alábbi Alapértelmezett ág 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 a Alapértelmezett ágban a manuális és ütemezett buildek mezőben.

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 frissítést küldek az adattárba.
• Sikertelen kivétel: A folyamat aktiválódik, de a kivételi lépés meghiúsul.
• Helytelen verziójú: A folyamat fut, de a forrás/YAML váratlan verzióját használja.
• Hiányzó állapotfrissítések: A GitHub-alapú számítógépeim 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 Triggerek lehetőséget a folyamat klasszikus szerkesztőjének megnyitásához. Ezután válassza YAML lapot, majd a Források lekérése lépést. Megjelenik egy transzparens, engedélyezve a kapcsolat használatával: 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:

  • Azure Pipelines-alkalmazás GitHub-alkalmazáskapcsolatot jelez
  • oauth OAuth-kapcsolatot jelez
  • személyesaccesstoken PAT-hitelesítést jelez

Hogyan válthatok úgy a folyamatomra, hogy az OAuth helyett GitHub-alkalmazást használjak?

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. Navigáljon é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 választ, ezen a lapon felkeresheti a GitHub-alkalmazást a GitHub-szervezetből való eltávolításához és az újrakezdéséhez.
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 a Triggerek 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 GitHub-alkalmazáshitelesítési.
• OAuth használata esetén lásd OAuth-hitelesítés.
• Ha PAT-eket használ, tekintse meg személyes hozzáférési jogkivonat (PAT) hitelesítésicímű témakört.

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írják a YAML CI- vagy PR-eseményindítókat, felül vannak bírálva a felhasználói felületifolyamatbeállításai? A folyamat szerkesztése közben válassza a ..., majd Triggereklehetőséget.

  

  Ellenőrizze az A YAML-eseményindító felülbírálása innen beállításnál az adattárhoz elérhető triggertípusok (folyamatos integrációs vagy lekéréses kérelmek érvényesítése) beállítását.

  

• A GitHub alkalmazáskapcsolatot használja a folyamat GitHubhoz való csatlakoztatásához? A kapcsolat típusának meghatározásához tekintse meg 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 beállítva szervezet, hogy ezt az adattárat az alkalmazás használatával hozza létre, lépjen 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 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 jelölje be a Beállítások jelölőnégyzetet. 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 a állapotlapon. 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 a Triggerek menüre.
3. Válassza A YAML folyamatos integrációs eseményindító felülbírálása innen.
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 javíthatom ki?

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. Miért van ez?

• 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 eseményindítók
• folyamatkiegészítési eseményindítók