Řízení spuštění pracovního postupu pomocí triggerů
Teď máte pracovní pracovní postup, který nasadí soubor Bicep do vašeho prostředí Azure. Kdykoli ale změníte soubor, musíte pracovní postup spustit ručně. V této lekci se dozvíte, jak aktivovat pracovní postup tak, aby se spouštěl automaticky při každé změně kódu Bicep.
Poznámka:
Příkazy v této lekci jsou znázorněny pro ilustraci konceptů. Zatím nespouštět příkazy. Brzy si procvičíte, co se tady naučíte.
Co je trigger pracovního postupu?
Trigger pracovního postupu je podmínka, která při splnění automaticky spouští pracovní postup na základě pravidel, která vytvoříte. Triggery můžete nastavit tak, aby se pracovní postup spouštějí v naplánovaných intervalech. Můžete také nastavit triggery pro spuštění pracovního postupu při každé změně souboru v úložišti. Můžete zvolit druhou možnost, protože je vhodné spustit všechny testy a kroky nasazení pokaždé, když někdo změní váš kód.
Pokud nepoužíváte automatickou aktivační událost, může někdo provést změnu souboru Bicep a dokonce ho potvrdit a odeslat do úložiště, ale pokud tento pracovní postup zapomene spustit, bude mezi definicemi prostředků v souboru Bicep a prostředky nasazenými do vašeho prostředí Azure rozdíl. Předpokládejme, že se vytvoří několik dalších potvrzení a nabízených oznámení, ale nenasadí se. Pokud někdo v souboru Bicep v některé z těchto změn zavádí chybu nebo špatnou konfiguraci, může být obtížné zjistit chybu mezi několika potvrzeními, která jsou později nasazena najednou. Po nějaké době nebudete důvěřovat tomu, že váš kód Bicep skutečně představuje vaši infrastrukturu a její hodnota je narušena.
Když nastavíte pracovní postup tak, aby běžel při každé aktualizaci souborů, spustí se váš pracovní postup v okamžiku, kdy se změny nasdílí. Získáte okamžitou zpětnou vazbu k platnosti změny a můžete mít jistotu, že vaše produkční prostředí je vždy aktuální.
Triggery nabízených událostí
Běžným typem triggeru je aktivační událost nabízená oznámení, označovaná také jako trigger kontinuální integrace nebo trigger CI. Když použijete trigger události nabízení, spustí se pracovní postup pokaždé, když provedete změnu konkrétní větve. Pokud potvrdíte a nasdílíte změnu do jiné větve, pracovní postup se neaktivuje a nespustí se. Tento typ triggeru se běžně používá pro výchozí nebo hlavní větev s tímto kódem:
on:
push:
branches:
- main
Aktivace při změně více větví
Triggery můžete nastavit pro spuštění pracovního postupu v konkrétní větvi nebo v sadách větví. Předpokládejme například, že vytvoříte větve vydané verze, které obsahují kód, který nasadíte pro konkrétní verzi projektu. Můžete použít názvy větví, jako jsou release/v1, release/v2 atd. Pracovní postup chcete spustit pokaždé, když se váš kód změní ve větvi, která začíná vydáním názvu /. Můžete použít ** zástupný znak:
on:
push:
branches:
- main
- 'release/**'
Můžete také vyloučit konkrétní větve. Předpokládejme, že spolupracujete s členy týmu na projektu. Vaši kolegové vytvářejí větve funkcí, aby si vyzkoušeli své nápady v souborech Bicep. Všechny větve funkcí mají názvy, jako jsou funkce, doplňková databáze, funkce/ zlepšení výkonu atd. Pracovní postup chcete spouštět automaticky ve všech větvích s výjimkou větví funkcí, které vaši kolegové vytvářejí. exclude Pomocí vlastnosti zajistíte, že se pracovní postup automaticky neaktivuje pro změny větví funkcí:
on:
push:
branches-ignore:
- 'feature/**'
Poznámka:
Určité větve můžete vyloučit pomocí znaku ! . Předpokládejme, že chcete aktivovat pracovní postup pro hlavní větev a všechny větve vydaných verzí s výjimkou verzí alfa. Tento znak můžete použít ! k vyjádření tohoto:
on:
push:
branches:
- main
- 'release/**'
- '!release/**-alpha'
V jednom triggeru nemůžete používat branches a branches-ignore společně, takže ! vám znak poskytuje flexibilitu pro řízení chování triggeru.
Filtry cest
Někdy máte ve svém úložišti soubory, které nesouvisí s vaším nasazením. V úložišti můžete mít například složku pro nasazení , která obsahuje kód Bicep a podsložku dokumentace, která obsahuje vaše soubory dokumentace. Pracovní postup chcete aktivovat, když někdo provede změnu některého ze souborů Bicep ve složce nasazení , ale nechcete pracovní postup aktivovat, pokud někdo změní jenom soubor dokumentace. Pokud chcete nastavit trigger pro reakci na změny v konkrétní složce v úložišti, můžete použít filtr cesty:
on:
push:
paths:
- 'deploy/**'
- '!deploy/docs/**'
Pokud někdo potvrdí změnu, která aktualizuje jenom soubor dokumentace, pracovní postup se nespustí. Ale pokud někdo změní soubor Bicep, nebo i když změní soubor Bicep vedle souboru dokumentace, trigger spustí pracovní postup.
Poznámka:
Můžete také použít paths-ignore, který funguje podobným způsobem jako klíčové branches-ignore slovo. Nemůžete ale použít paths a paths-ignore ve stejném triggeru.
Naplánování automatického spuštění pracovního postupu
Pracovní postup můžete spustit podle nastaveného plánu, a ne v reakci na změnu souboru. Můžete například spustit noční vydání kódu Bicep nebo automaticky nasadit testovací prostředí každé ráno. schedule Použijte klíčové slovo a nastavte frekvenci pomocí výrazu cron:
on:
schedule:
- cron: '0 0 * * *'
Poznámka:
Výraz cron je speciálně naformátovaná posloupnost znaků, která určuje, jak často se má něco stát. V tomto příkladu znamená spuštění 0 0 * * * každý den o půlnoci UTC.
V souboru YAML je potřeba přidat uvozovky kolem řetězců, které obsahují * znak, například výrazy cron.
Událost plánu vždy spouští pracovní postup ve výchozí větvi úložiště.
Použití více aktivačních událostí
Triggery a plány můžete kombinovat, například v tomto příkladu:
on:
push:
branches:
- main
schedule:
- cron: '0 0 * * *'
Když vytvoříte trigger větve a naplánovanou aktivační událost ve stejném pracovním postupu, pracovní postup se spustí při každé změně souboru ve větvi nastavené v triggeru a v plánu, který jste nastavili. V tomto příkladu se pracovní postup spouští každý den o půlnoci UTC a také při každém vložení změny do hlavní větve.
Tip
Je vhodné nastavit triggery pro každý pracovní postup. Pokud ve výchozím nastavení nenastavíte triggery, pracovní postup se automaticky spustí při každé změně souboru v libovolné větvi, což často není to, co chcete.
Triggery webhooku
GitHub také poskytuje události webhooku, které se spouští automaticky, když dojde k určitým událostem ve vašem úložišti. Mezi tyto události patří někdo, kdo vytváří větev, aktualizuje problémy GitHubu nebo mění žádosti o přijetí změn. Obecně platí, že tyto události nevyžadují spuštění pracovního postupu nasazení Bicep, ale místo toho můžete spustit jinou automatizaci.
Řízení souběžnosti
GitHub Actions ve výchozím nastavení umožňuje souběžné spouštění více instancí pracovního postupu. K tomu může dojít, když provedete několik potvrzení do větve během krátké doby nebo pokud se předchozí spuštění nedokončilo, když se plán další aktivační události aktivuje.
V některýchsituacích Když ale pracujete s pracovními postupy nasazení, může být náročné zajistit, aby vaše spuštění pracovního postupu nepřepsala prostředky Azure ani konfiguraci způsobem, který neočekáváte.
Abyste se těmto problémům vyhnuli, můžete použít řízení souběžnosti. concurrency Použijte klíčové slovo a pak zadejte řetězec, který je konzistentní napříč všemi spuštěními vašeho pracovního postupu. Obvykle se jedná o pevně zakódovaný řetězec, například v tomto příkladu:
concurrency: MyWorkflow
GitHub Actions pak zajistí, že před spuštěním nového spuštění počká na dokončení aktivního pracovního postupu.