Lekéréses kérelem munkafolyamatainak testreszabása és kiterjesztése lekéréses kérelmek állapotával

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

A lekéréses kérelmek nagyszerű eszköznek számítanak a kódvizsgálatok megkönnyítésére és a kódáthelyezés kezelésére egy adattárban. A fiókszabályzatok a lekéréses kérelem folyamata során a kódminőséget úgy kényszerítik ki, hogy olyan követelményeket állapítanak meg, amelyeket minden kódmódosításhoz végre kell hajtani. Ezek a szabályzatok lehetővé teszik a csapatok számára a kód áttekintésével és az automatizált buildek futtatásával kapcsolatos számos ajánlott eljárás kikényszerítését, de számos csapat további követelményeket és érvényesítési műveleteket hajthat végre a kódon. Az egyéni és egyéni igények kielégítése érdekében az Azure Repos lekéréses kérelmek állapotát kínálja. A lekéréses kérelmek állapotai integrálhatók a lekéréses kérelem munkafolyamatába, és lehetővé teszik a külső szolgáltatások számára, hogy programozott módon jelentkezzenek ki egy kódmódosításról, ha egyszerű sikeres/sikertelen típusadatokat társítanak egy lekéréses kérelemhez. Igény szerint a lekéréses kérelmek blokkolhatók, amíg a külső szolgáltatás nem hagyja jóvá a módosítást.

A PR-munkafolyamatba való integrálás néhány különböző fogalomból áll:

• Lekéréses kérelmek állapota – lehetővé teszi a szolgáltatások számára a sikeres/sikertelen adatok lekéréses kérelmekhez való társítását.
• Állapotházirend – a lekéréses kérelmek befejezésének letiltására szolgáló mechanizmus, amíg a lekéréses kérelem állapota nem jelzi a sikerességet.
• Egyéni műveletek – lehetővé teszi az állapotmenü kibővítését az Azure DevOps Services-bővítmények használatával.

Ebben a témakörben megismerkedhet a lekéréses kérelmek állapotával, valamint azzal, hogyan integrálhatók a lekéréses kérelmek munkafolyamatában.

Lekéréses kérelem állapota

A lekéréses kérelmek állapota lehetővé teszi, hogy a szolgáltatások egyszerű sikeres/sikertelen típusú adatokat társítjanak egy lekéréses kérelemhez az Állapot API használatával. Az állapot négy kulcsfontosságú adatból áll:

• Állapot. Az alábbi előre definiált állapotok egyike: succeeded, , failedpending, notSet, notApplicablevagy error.
• Leírás. A végfelhasználónak az állapotot leíró sztring.
• Környezet. Az állapot neve – általában az állapotot közzételő entitás leírása.
• URL-cím. Egy hivatkozás, ahol a felhasználók további információkat kaphatnak az állapotról.

Az állapot lényegében az, ahogyan egy felhasználó vagy szolgáltatás közzéteheti kiértékelését egy lekéréses kérelemről, és választ ad az olyan kérdésekre, mint például:

• A módosítások megfelelnek a követelményeknek?
• Hol tudhatok meg többet arról, hogy mit kell tennem a követelmények teljesítéséhez?

Lássunk egy példát. Fontolja meg egy CI-szolgáltatást , amely a projekt összes kódmódosításának létrehozásához szükséges. Amikor a szolgáltatás kiértékeli egy lekéréses kérelem módosításait, közzé kell tennie a build és a tesztek eredményeit. A buildet átadó módosítások esetén az alábbihoz hasonló állapot jelenhet meg a lekéréses kérelemben:

{
    "state": "succeeded",
    "description": "CI build succeeded",
    "context": {
        "name": "my-ci-system",
        "genre": "continuous-integration"
    },
    "targetUrl": "http://contoso.com/CI/builds/1"
}

Ez az állapot a végfelhasználó számára jelenik meg a lekéréses kérelem részletei nézetben:

• Ez state ikonnal jelenik meg a felhasználó számára (zöld pipasucceeded, piros X, failedóra pendingés piros ! ).error
• Ez description az ikon mellett jelenik meg, és az context elemleírásban érhető el.
• Ha alkalmaz egy targetUrl leírást, a leírás az URL-címre mutató hivatkozásként jelenik meg.

Állapot frissítése

A szolgáltatás további állapotok közzétételével frissítheti az egyes pr-szolgáltatások pr-állapotát, amelyek közül csak a legújabb jelenik meg az egyes egyedi contextpéldányok esetében. A több állapot közzétételével a felhasználók kezelhetik az elvárásokat. Az állapot közzététele pending például jó módja annak, hogy a felhasználó nyugtázza, hogy egy rendszer eseményt kapott, és megkezdi a munkát. A következő példákhoz hasonló informatív description példákkal a felhasználó könnyebben megértheti a rendszer működését:

• "Build queued"
• "Fejlesztés folyamatban"
• "Sikeres buildelés"

Iteráció állapota

Amikor egy lekéréses kérelem forrásága megváltozik, egy új "iteráció" jön létre a legújabb módosítások nyomon követéséhez. A kódmódosításokat kiértékelő szolgáltatások új állapotot szeretnének közzétenni a lekéréses kérelem minden iterációján. A lekéréses kérelem adott iterációjába való közzététel garantálja, hogy az állapot csak a kiértékelt kódra és a jövőbeli frissítésekre vonatkozik.

Feljegyzés

Ha a létrehozott lekéréses kérelem több mint 100 000 módosított fájlt tartalmaz, akkor teljesítmény- és stabilitási okokból a pr nem támogatja az iterációkat. Ez azt jelenti, hogy az ilyen lekéréses kérelem minden további módosítást tartalmaz, de a módosításhoz nem jön létre új iteráció. Ezenkívül a nem létező iterációk állapotának létrehozására tett kísérletek hibát fognak visszaadni.

Ezzel szemben, ha a közzétett állapot a teljes lekéréses kérelemre vonatkozik, a kódtól függetlenül szükségtelen lehet az iterációba való közzététel. Például annak ellenőrzése, hogy a szerző (egy nem módosítható PR-tulajdonság) egy adott csoporthoz tartozik-e, csak egyszer kell kiértékelni, és nincs szükség iterációs állapotra.

Az állapotházirend konfigurálásakor, ha iterációs állapotot használ, az alaphelyzetbe állítási feltételeket alaphelyzetbe állítási állapotra kell állítani, amikor új módosítások történnek. Ez garantálja továbbá, hogy a lekéréses kérelem nem egyesíthető addig, amíg a legújabb iteráció állapota succeedednem lesz .

Tekintse meg a REST API-példákat az állapot iteráción és lekéréses kérelmeken való közzétételéhez.

Állapotszabályzat

Ha csak az állapotot használja, a külső szolgáltatásból származó adatokat a lekéréses kérelem felületén keresztül is megadhatja a felhasználóknak. Néha a lekéréses kérelmekkel kapcsolatos információk megosztása szükséges, más esetekben azonban a kérelemkérési kérelmeket le kell tiltani az egyesítéstől a követelmények teljesítéséig. A beépített szabályzatokhoz hasonlóan az Állapotszabályzat is lehetővé teszi, hogy a külső szolgáltatások blokkolják a lekéréses kérelem teljesítését a követelmények teljesítéséig. Ha a szabályzatra szükség van, a lekéréses kérelem végrehajtásához át kell adnia. Ha a szabályzat nem kötelező, csak tájékoztató jellegű, és succeeded a lekéréses kérelem végrehajtásához nincs szükség állapotra.

Az állapotszabályzatok ugyanúgy vannak konfigurálva, mint más ágszabályzatok. Új állapotházirend hozzáadásakor meg kell adni az állapotházirend nevét és műfaját . Ha az állapot már korábban fel lett adva, kiválaszthatja a listából; ha új szabályzatról van szó, a formátum műfajának/nevében beírhatja a szabályzat nevét.

Ha egy állapotházirend succeeded meg van adva, a kiválasztott névvel context egyező állapotnak kell jelen lennie ahhoz, hogy ez a szabályzat áthaladjon.

Egy jogosult fiók is kiválasztható, amely megköveteli, hogy egy adott fiók közzétehesse a szabályzatot jóváhagyó állapotot.

Szabályzat alkalmazhatósága

A Szabályzat alkalmazhatósági beállításai határozzák meg, hogy a szabályzat a lekéréses kérelem létrehozásakor azonnal érvényes-e, vagy hogy a szabályzat csak az első állapot lekéréses kérelemre való közzététele után érvényes-e.

1. Alapértelmezés szerint alkalmazva – A szabályzat a lekéréses kérelem létrehozásakor azonnal érvényes lesz. Ezzel a beállítással a szabályzat nem halad át a lekéréses kérelem létrehozása után, amíg succeeded az állapot fel nem kerül. A lekéréses kérelem a szabályzat alól mentesítettként megjelölhető egy állapot notApplicableközzétételével, amely eltávolítja a szabályzatkövetelményt.

2. Feltételes – A szabályzat csak akkor érvényes, ha az első állapot megjelenik a lekéréses kérelemben.

Ezek a lehetőségek együttesen dinamikus szabályzatok egy csomagjának létrehozásához használhatók. A legfelső szintű "vezénylési" szabályzatok alapértelmezés szerint alkalmazhatók, miközben a lekéréses kérelem kiértékelése folyamatban van az alkalmazható szabályzatok esetében. Ezután, mivel további feltételes szabályzatok alkalmazásának meghatározása (esetleg adott buildkimenet alapján) van meghatározva, az állapot közzétehető, hogy szükség legyen rájuk. Ez a vezénylési szabályzat megjelölhető succeeded , ha befejeződött az értékelés, vagy megjelölhető notApplicable , hogy jelezze a lekéréses kérelemnek, hogy a szabályzat nem érvényes.

Egyéni műveletek

Azon előre definiált szolgáltatáshook-események mellett, amelyek aktiválhatják a szolgáltatást a PR állapotának frissítéséhez, az állapotmenüt az Azure DevOps Services bővítményeivel is kiterjesztheti, hogy triggerműveleteket adjon a végfelhasználónak. Ha például az állapot egy olyan tesztfuttatásnak felel meg, amelyet a végfelhasználó újraindíthat, lehetséges , hogy egy Újraindítás menüelem található az állapotmenüben, amely teszteket indítana el a futtatáshoz. Állapotmenü hozzáadásához a hozzájárulási modellt kell használnia. További információkért tekintse meg az Azure DevOps-bővítmény mintáját.

Következő lépések

További információ a PR Status API-ról , és tekintse meg az útmutatókat:

• Lekéréses kérelem állapotkiszolgáló létrehozása Node.js
• Egyéni ágszabályzatok létrehozása az Azure Functionsszel
• Ágszabályzat konfigurálása külső szolgáltatásra vonatkozóan