Bitbucket Cloud-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 Bitbucket Cloud-adattárat. Ez a cikk a Bitbucket Cloud és az Azure Pipelines közötti integráció konfigurálását ismerteti.

A Bitbucket és az Azure Pipelines két független szolgáltatás, amelyek jól integrálhatók egymással. A Bitbucket Cloud felhasználói nem kapnak automatikusan hozzáférést az Azure Pipelineshoz. Ezeket explicit módon kell hozzáadnia az Azure Pipelineshoz.

Access to Bitbucket repositories

YAML

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

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

Klasszikus

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

Az Azure Pipelinesnak hozzáférést kell biztosítani az adattárakhoz, hogy lekérje a kódot a buildek során. Emellett a folyamatot állító felhasználónak rendszergazdai hozzáféréssel kell rendelkeznie a Bitbuckethez, mivel az identitással regisztrál egy webhookot a Bitbucketben.

A folyamat létrehozásakor az Azure Pipelines két hitelesítési típussal rendelkezik, amelyek hozzáférést biztosítanak a Bitbucket Cloud-adattárakhoz.

Hitelesítés típusa	A folyamatok a következő használatával futnak:
1. OAuth	Személyes Bitbucket-identitás
2. Felhasználónév és jelszó	Személyes Bitbucket-identitás

OAuth-hitelesítés

Az OAuth a legegyszerűbb hitelesítési típus a Bitbucket-fiók adattárainak első lépéseihez. A Bitbucket állapotfrissítései a személyes Bitbucket-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.

Az OAuth használatához jelentkezzen be a Bitbucketbe, amikor a folyamat létrehozása során kéri. Ezután kattintson az Engedélyezés gombra az OAuth-hitelesítés engedélyezéséhez. A rendszer egy OAuth-kapcsolatot ment az Azure DevOps-projektben későbbi használatra, valamint a létrehozott folyamathoz.

Megjegyzés:

Az Azure DevOps Services felhasználói felülete által betölthető Bitbucket-adattárak maximális száma 2000.

Jelszavas hitelesítés

A buildek és a Bitbucket állapotfrissítései a személyes 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.

Jelszókapcsolat létrehozásához keresse fel a szolgáltatáskapcsolatokat az Azure DevOps-projekt beállításai között. Hozzon létre egy új Bitbucket-szolgáltatáskapcsolatot, és adja meg a felhasználónevet és a jelszót a Bitbucket Cloud-adattárhoz való csatlakozáshoz.

CI-eseményindítók

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

YAML

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

Ágak

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

trigger:
- main
- releases/*

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

Megjegyzés:

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

Megjegyzés:

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

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

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

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

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

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

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

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

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

Fontos

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

CI-futtatások kötegelése

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

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

Megjegyzés:

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

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

Megjegyzés:

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

Elérési utak

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

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

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

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

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

Megjegyzés:

A Bitbucket Cloud-adattárak esetében a szintaxis használata branches az egyetlen módja a címke eseményindítóinak megadásának. A tags: szintaxis a Bitbucket esetében nem támogatott.

A CI-ről való lemondás

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

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

# A pipeline with no CI trigger
trigger: none

Fontos

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

Klasszikus

Megjegyzés:

A Build.SourceVersionMessage változó nem működik a Bitbucket-adattárakkal, ha a Batch megváltozik, miközben a build engedélyezve van .

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

Batch-módosítások

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

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

Megjegyzés:

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

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

Ágszűrők

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

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

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

Tips:

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

Példa

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

Ci kihagyása egyéni véglegesítésekhez

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

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

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

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

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

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

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

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

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

Helyettesítő karakterek

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

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

trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR-eseményindítók

A lekéréses kérelem (PR) eseményindítói azt okozzák, hogy a folyamat akkor fut, amikor egy lekéréses kérelmet az egyik megadott célággal nyitnak meg, vagy amikor frissítéseket végeznek egy ilyen lekéréses kérelemen.

YAML

Ágak

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

pr:
- main
- releases/*

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

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

Megjegyzés:

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

Megjegyzés:

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

Minden új futtatás a lekéréses kérelem forráságából hozza létre a legújabb véglegesítést. Ez eltér attól, ahogyan az Azure Pipelines lekéréses kérelmeket készít más adattárakban (például Azure Repos vagy GitHub), ahol az egyesítési véglegesítést hozza létre. Sajnos a Bitbucket nem tesz közzé információkat az egyesítési véglegesítésről, amely a lekéréses kérelem forrás- és célágai közötti egyesített kódot tartalmazza.

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

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

Fontos

Eseményindító megadásakor pr az alapértelmezett implicit pr 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.

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

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

Elérési utak

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

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

Tips:

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

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 kérelemhez tartozó folyamatban lévő érvényesítési futtatásokat. Az alapértelmezett érték true.

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

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

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

# no PR triggers
pr: none

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

Megjegyzés:

Ha az pr eseményindító nem aktiválódik, győződjön meg arról, hogy nem bírálta felül a YAML PR-eseményindítókat a felhasználói felületen.

Klasszikus

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

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

Információs futtatások

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

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

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

• Az állapot: Canceled
• Az időtartam: < 1s
• A futtatás neve a következő szövegek egyikét tartalmazza:
  • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
  • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
  • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
  • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
• A futtatás neve általában azt a BitBucket/GitHub-hibát tartalmazza, amely miatt a YAML-folyamat betöltése meghiúsult
• Nincsenek fázisok / feladatok / lépések

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

Korlátozások

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 manuális és ütemezett buildek alapértelmezett ágába, vagy amikor egy folyamat manuális futtatásakor kiválaszt egy ágat. Ha nem látja a kívánt ágat a listában, manuálisan írja be a kívánt ágnevet.

GYIK

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

• Sikertelen eseményindítók: A folyamat nem aktiválódik, amikor frissítést küldek az adattárba.
• Helytelen verzió: A folyamat fut, de a forrás/YAML váratlan verzióját használja.

Sikertelen eseményindítók

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

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

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

  

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

  

• A webhookok a Bitbucket és az Azure Pipelines frissítéseinek közlésére szolgálnak. A Bitbucketben keresse meg az adattár beállításait, majd a Webhookokat. Ellenőrizze, hogy léteznek-e webhookok.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Helytelen verzió

A folyamat a YAML-fájl nem megfelelő verzióját használja. Miért?

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