ProHoster > Blog > Adminisztráció > A GitHub CI/CD-ként működik a statikus generátor webhelyhez és a GitHub-oldalakhoz
A GitHub CI/CD-ként működik a statikus generátor webhelyhez és a GitHub-oldalakhoz
Kicsit átkutatva Habrt, meglepett, hogy nagyon kevés cikk jelent meg a GitHub (béta) funkciójáról - Actions.
Úgy tűnik, hogy az ilyen alulértékelés azzal magyarázható, hogy a funkcionalitás még tesztelés alatt áll, bár „béta”. De ez a béta hasznos funkciója, amely lehetővé teszi ennek az eszköznek a használatát magántárolókban. Ebben a cikkben az ezzel a technológiával való munkavégzésről fogok beszélni.
Őstörténet
Ha sorrendben kezdjük, akkor talán érdemes megemlíteni, hogy egy személyes „Rólam” weboldal tárolására szolgáló gyors, kényelmes, egyszerű és ingyenes lehetőség keresése során több éjszakát kellett eltöltenem és rengeteg cikket átfésülve.
Vannak, akik a tárhelyet választják, mások a felhőszervert, akik pedig nem akarják megérteni ennek a munkáját, interakcióját és fizetését, például statikus oldalakat töltenek fel egy adattárba, hiszen ez most már GitHubon és GitLabon is megtehető.
Természetesen ez mindenki egyéni döntése.
A végső választásom a GitHub Pages volt.
Az oldalakról
Aki nincs tisztában gh-pages - ez egy lehetőség a dokumentáció weboldal formájában történő tárolására, és ingyenesen biztosított, illetve a dokumentáció mellett javasolt személyes weboldalak tárolása is. Ezt a funkciót a GitHub biztosítja minden felhasználó számára, és elérhető a lerakat beállításaiban.
A projekttár ágat használ gh-pages, felhasználói webhelyhez - külön tárhely a névvel username.github.io a webhely forrásaival master ág.
További részleteket láthat a dokumentációban, de hadd jegyezzem meg, hogy a GitHub meglepően nagylelkű abban, hogy bárki hozzákapcsolja a saját domainjét egy ilyen webhelyhez egy fájl hozzáadásával. CNAME a tartománynévvel, és állítsa be a tartományszolgáltató DNS-ét a GitHub szervereken.
Biztos vagyok benne, hogy sok cikk található itt arról, hogyan lehet egy ilyen webhelyet fejleszteni, ezért nem erről fogok a továbbiakban beszélni.
Felmerülő probléma
A probléma az volt, hogy statikus generátor használatakor szükség van további szkriptek írására és könyvtárak használatára, amelyek leegyszerűsítik az oldalak generálását és a tárolóba való betöltését. Egyszerűen, ha a forrásokat egy külön privát tárolóban tárolja, akkor minden alkalommal, amikor bármilyen változás történik a webhelyen, szükség volt a helyi környezet telepítésére a statikus oldalak későbbi generálásához és a fő webhely tárolójában való közzétételhez.
Van bőség statikus generátorok és mindegyiknek ugyanaz a problémája. Ezek a műveletek túl sok időt és erőfeszítést igényelnek, és végső soron lelassítják a webhelyen végzett munkát, különösen az operációs rendszerről az operációs rendszerre történő többszöri migráció vagy a merevlemez-meghajtók adatvesztésével járó események után. (az én esetemben ez volt a helyzet).
A közelmúltban, akár egy felugró értesítésben a webhelyen, akár a GitHub hírlevelében, egy újonnan épített CI/CD-t vettek észre, amely lehetővé tette, hogy ezeket a műveleteket minimális erőfeszítéssel elvégezzék.
A statikus oldalgenerátorokról
Nem fogok különösebb figyelmet fordítani erre az alpontra, de megosztok pár tézist, amelyekre a következők kiválasztása és használata során jutottam:
1) válasszon egy generátort, amely megfelel a programozási nyelvének, vagy egy olyan, amely a lehető legegyértelműbb. Akkor jutottam erre az ötletre, amikor nekem magamnak kellett néhány funkciót hozzáadnom ahhoz, hogy a webhely működjön, és mankókat kellett hozzáadnom a nagyobb stabilitás és automatizálás érdekében. Ezen túlmenően ez jó ok arra, hogy saját maga írjon további funkciókat bővítmények formájában;
2) hogy melyik generátort választjuk, az egyéni döntés, de érdemes megfontolni, hogy a GitHub Pages működésében való kezdeti elmerüléshez először telepítenie kell Jekyll. Szerencsére lehetővé teszi, hogy közvetlenül a tárhelyben lévő forrásokból webhelyet hozzon létre (Ezt megismétlem a választásommal).
A generátorválasztásom az első ponton alapul. Pelikán ami Pythonban van írva, könnyen felváltotta a számomra idegen Jekyllt (majdnem egy évig használt). Ebből kifolyólag még a cikkek készítése és szerkesztése, valamint a weboldalon való munka is plusz tapasztalatot ad egy számomra érdekes nyelven.
__
Probléma nyilatkozat
A fő feladat egy szkript (valójában egy konfigurációs fájl) megírása lesz, amely automatikusan statikus oldalakat generál egy privát tárolóból. A megoldás egy virtuális környezet funkcionalitását foglalja magában. Maga a szkript kész oldalakat fog hozzáadni a nyilvános tárolóhoz.
Eszközök a megoldáshoz
Eszközök, amelyeket a probléma megoldására használunk:
GitHub-műveletek;
Python 3.7;
Pelikán;
Git;
GitHub oldalak.
Az oldat
Tehát miután kicsit megismerkedtünk a dokumentációval és megértették, hogyan készülnek a műveletek szkriptjei, világossá vált, hogy ez a mechanizmus teljesen megoldja a felmerült problémát. A cikk írásakor elő kell fizetnie a funkció használatához.béta teszteléshez!
Az új funkció leírása a Github által
Az Actions script írása egy elnevezett fájl létrehozásával kezdődik egy mappában .github és annak almappája workflows. Ez megtehető manuálisan vagy a tároló oldal Műveletek lapjának szerkesztőjéből.
Példa egy üres script űrlapra
Röviden kommentálom az űrlapot
name: CI # название скрипта: будет отображаться во вкладке Actions
on: [push] # действие, по которому запускается данный скрипт
jobs: # роботы, которые будут выполняться
build: # сборка, которая..
runs-on: ubuntu-latest # ..будет запущена на основе этого образа
steps: # шаги которые будут проделаны после запуска образа
- uses: actions/checkout@v1 # переход в самую актуальную ветку
- name: Run a one-line script # имя работы номер 1
run: echo Hello, world! # суть работы номер 1 (bash-команда записана в одну строку)
- name: Run a multi-line script # имя работы номер 2
run: | # суть работы номер 2 (многострочная)
echo Add other actions to build,
echo test, and deploy your project.
Írjuk meg a sajátunkat a sablon alapján:
0) Meghagyhatja a „CI” nevet is. Ízlés kérdése.
1) Ezután ki kell választani azt a műveletet/triggert, amely elindítja a szkriptet, esetünkben ez egy új commit szokásos push a repository-ba.
on:
push
2) Példaként meghagyjuk azt a képet is, amely alapján a szkript elindul, mivel az Ubuntu teljesen elégedett a szükséges funkciókkal. Ránéz rendelkezésre álló eszközöket világossá válik, hogy ez lehet bármilyen szükséges vagy egyszerűen kényelmes kép (vagy egy Docker konténer az alapján).
build:
runs-on: ubuntu-latest
3) A lépésekben először felállítjuk a környezetet, hogy felkészüljünk a fő munkára.
3.1) menjünk a szükséges fiókhoz (normál lépés checkout):
- uses: actions/checkout@v1
3.2) Telepítse a Python-t:
- name: Set up Python
uses: actions/setup-python@v1
with:
python-version: 3.7
3.4) hozzon létre egy könyvtárat, amelyben a webhely oldalai jönnek létre:
- name: Make output folder
run: mkdir output
4) Annak érdekében, hogy az oldalon végzett munka konzisztens legyen, nevezetesen, hogy ne töröljék a korábbi változtatásokat, és ütközések nélkül lehessen változtatásokat hozzáadni a webhelytárhoz, a következő lépés a webhelytár minden egyes alkalommal történő klónozása:
változó GITHUB_ACTOR A GitHub telepíti magát, és ez az a felhasználónév, amelynek hibájából ez a szkript elindult;
változó secrets.ACCESS_TOKEN ez keletkezik token a Github kezeléséhez, a lapon beállítva környezeti változóként adhatjuk át Secrets a tárhely beállításainkat. Kérjük, vegye figyelembe, hogy a generálás során a tokent egyszer kapjuk meg, többé nem lesz elérhető. Valamint a Secrets tételek értékei.
A generátornak átadott paraméterek felelősek azért a könyvtárért, ahová a generált fájlok elküldésre kerülnek (-o output) és az általunk generált konfigurációs fájl (-s publishconf.py; A helyi konfiguráció és a konfiguráció szétválasztásának módjáról a Pelican dokumentációjában olvashat).
Hadd emlékeztesselek, mi van a mappánkban output A webhely tárházát már klónozták.
6) Állítsuk be a git-et, és indexeljük a megváltozott fájljainkat:
Ekkor a rendszer egy már ismert változót használ, és jelzi azt a munkakönyvtárat, amelyben az ebből a lépésből származó parancsok elindulnak. A munkakönyvtárba ugrás parancs egyébként így nézne ki: cd output.
7) Hozzunk létre egy véglegesítési üzenetet, véglegesítsük a változtatásokat, és toljuk be a tárolóba. Annak érdekében, hogy a véglegesítés ne legyen hiábavaló, és ezért ne okozzon hibát a bash-ban (a kimeneti eredmény nem 0) — először is nézzük meg, hogy szükséges-e egyáltalán valamit elkötelezni és nyomni. Ehhez a parancsot használjuk git diff-index --quiet --cached HEAD -- amely a terminálra fog kimenni 0 ha nincs változás az oldal előző verziójához képest, és 1 vannak ilyen változások. Ezután feldolgozzuk a parancs eredményét. Így a szkript végrehajtásával kapcsolatos információkban hasznos információkat rögzítünk az oldal jelenlegi állapotáról, ahelyett, hogy automatikusan összeomolnánk és jelentést küldenénk a szkript összeomlásáról.
Ezeket a műveleteket a címtárunkban is végrehajtjuk kész oldalakkal.
- name: Push and send notification
run: |
COMMIT_MESSAGE="Update pages on $(date +'%Y-%m-%d %H:%M:%S')"
git diff-index --quiet --cached HEAD -- && echo "No changes!" && exit 0 || echo $COMMIT_MESSAGE
# Only if repo have changes
git commit -m "${COMMIT_MESSAGE}"
git push https://${{ secrets.ACCESS_TOKEN }}@github.com/${GITHUB_ACTOR}/${GITHUB_ACTOR}.github.io.git master
working-directory: ./output
Eredmény
Ennek eredményeként egy ilyen szkript lehetővé teszi, hogy ne gondoljon statikus oldalak létrehozására. Ha a változtatásokat közvetlenül egy privát adattárhoz adjuk hozzá, akár a git-tel dolgozunk bármilyen rendszerből, akár egy fájlt hozunk létre a GitHub webes felületén keresztül, az Actions mindent maga fog elvégezni. Ha a szkript váratlanul összeomlik, értesítést küldünk az Ön e-mail címére.
Teljes kód
Meghagyom a működő verziómat, amelyben az utolsó lépésben értesítést küldök arról, hogy a véglegesítést a fő tárolóba küldték.
A fent leírt Titkok használatára kerül sor, ahol a bot token és a felhasználói azonosító, akinek az üzenetet el kell küldeni, hozzáadásra kerül.