GitHub Actions: Bevált gyakorlatok


Ez egy élő dokumentum, amely a GitHub Actions használatához kapcsolódó bevált gyakorlatokat gyűjti össze. Ha bármilyen javaslatod vagy kiegészítésed van, nyiss egy pull requestet a GitHubon!

Bevált gyakorlatok gyűjteménye

Állíts be időtúllépést a workflowkhoz

A GitHub Actions alapértelmezés szerint 6 óra után leállítja a workflowkat, ha addig nem fejeződtek be. Sok workflownak közel sem kell ennyi idő a befejezéshez, de néha váratlan hibák lépnek fel, vagy egy job addig akad, amíg a workflow futását 6 órával az indítása után le nem állítják. Ezért érdemes rövidebb időtúllépést megadni.

Az ideális időtúllépés az adott workflowtól függ, de 30 perc általában bőven elég az Exercism repóiban használt workflowkhoz.

Ennek a következő előnyei vannak:

  • A PR-ek nem fognak fél napig a CI-re várni, a problémák korán kiderülnek, vagy a workflow-futások újraindíthatók.
  • Az egyidejű buildek száma összességében korlátozott, és a lefagyott jobok nem okoznak problémát más PR-eknek, ha korán megszakítják őket.

Példa

jobs:
  configlet:
    timeout-minutes: 30
    runs-on: ubuntu-latest
    steps:
      - [...]

Gondold át, valóban szükség van-e a (harmadik féltől származó) actionökre

Az actionöket úgy kell kezelni, mint a kedvenc programozási nyelved1 függőségeit: olyan kód ez, amelyet harmadik féltől származó szerzők írtak, az Exercism felügyeletén kívül. Még ha meg is bízol az action szerzőiben, előfordulhat, hogy a repositoryt ellenségesen átveszik, ami közvetve hozzáférést ad ezeknek az embereknek az Exercism repóihoz, írási jogosultságot is beleértve. Ezért alaposan gondold át, hogy valóban megéri-e bevezetni egy új actiont, vagy jobb, ha a kódot átmozgatod egy (új) actionbe, amely az Exercism felügyelete alatt áll. Azt is gondold át, hogy az actiont aktívan karbantartják-e, például a repó friss aktivitásának ellenőrzésével, vagy annak biztosításával, hogy az action egy szervezethez tartozik, nem pedig egyéni fiókhoz. A GitHub vagy az Exercism szervezete által közzétett actionök általában biztonságosnak (többé-kevésbé) tekinthetők, és különösebb megfontolás nélkül beépíthetők.

A workflow token scope-jának korlátozása

Alapértelmezés szerint a workflownak adott hozzáférési token széles körű jogosultságokkal rendelkezik, olvasásra és írásra egyaránt.

A legkisebb jogosultság elvét a workflowkra is alkalmazni kell.

Megadhatod, hogy egy workflow milyen jogosultságokat igényel, workflownként.

Példa

Ha egy workflow csak egy repó tartalmát szeretné olvasni, írni nem, például mert ez egy szokásos CI-ellenőrzés, a tokent a következőképpen korlátozhatod:

permissions:
  contents: read

A jogosultságok teljes listáját a GitHub Docs oldalon találod.

Rögzítsd az actionöket SHA-khoz

Amikor más actionöket használsz, egy commithoz rögzítsd őket (az SHA-jukon keresztül), ne egy branchhez vagy taghez. Ez biztosítja, hogy minden alkalommal ugyanaz a kód fusson le, ami nem garantált, ha egy branchhez vagy taghez rögzítesz.

Ennek két előnye van:

  1. Stabillá teszi a buildet
  2. Megakadályozza, hogy egy támadó egy brancht vagy taget rosszindulatú kódra mutatóra változtasson

Ez alól a szabály alól egyetlen kivétel lehetnek azok az actionök, amelyeket mi (az Exercism) magunk építettünk.

A commit SHA megkeresése

Általában egy adott kiadás commit SHA-jához szeretnél rögzíteni. Egy kiadás commit SHA-jának megkereséséhez nyisd meg az action repositoryjának releases oldalát (pl. https://github.com/actions/checkout/releases). Keresd meg a használni kívánt kiadást, és kattints a kiadás bal oldalán, az összefoglaló szakaszban szereplő rövid SHA-ra (pl. a12a394). Ezután átirányítanak a kiadás részleteit tartalmazó oldalra, ahol megtalálod a használható teljes commit SHA-t.

Példa

- name: Checkout code
  uses: actions/checkout@a12a3943b4bdde767164f792f33f40b04645d846

Rögzítsd a tesztfuttatókat verzióhoz

A legtöbb workflow a GitHub által támogatott futtatókon fut. Amikor ezek közül a futtatók közül használsz egyet, egy konkrét verziót adj meg a legfrissebb helyett.

Ez biztosítja, hogy a workflow mindig ugyanazon a futtatón fusson, ami stabillá teszi a buildet.

Példa

Használd:

runs-on: ubuntu-22.04

ahelyett, hogy:

runs-on: ubuntu-latest

Gondold át, beállíts-e egyidejűségi stratégiát

Gyakran nem szükséges és nem is hasznos CI-t futtatni a köztes commitokon, ha közben újabb commitot pusholtak.

Beállíthatsz egy egyidejűségi stratégiát, hogy automatikusan megszakítsd a futó workflowkat ugyanabban a kontextusban.

Példa

A PR-ben a köztes buildek megszakításához a következő egyidejűségi beállításokat használhatod:

concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: ${{ startsWith(github.ref, 'refs/pull/') }}
Harmadik féltől származó közlemény

A fenti példa a PkgTemplates.jl CI workflow-ján alapul, amely az MIT licenc alatt jelent meg:

MIT licenc

Copyright (c) 2017-2020 Chris de Graaf, Invenia Technical Computing Corporation

Ezúton engedélyt adunk díjmentesen minden olyan személynek, aki a szoftver és a kapcsolódó dokumentációs fájlok (a „Szoftver”) egy példányát megszerzi, hogy korlátozás nélkül foglalkozzon a Szoftverrel, beleértve korlátozás nélkül a használat, másolás, módosítás, összevonás, közzététel, terjesztés, alengedélyezés és/vagy eladás jogát, valamint hogy engedélyezze mindezt azoknak, akiknek a Szoftvert rendelkezésére bocsátja, az alábbi feltételekkel:

A fenti szerzői jogi közleményt és ezt az engedélyezési közleményt minden másolatba vagy a Szoftver jelentős részébe be kell foglalni.

A SZOFTVERT „ADOTT ÁLLAPOTÁBAN” BIZTOSÍTJUK, BÁRMILYEN KIFEJEZETT VAGY VÉLELMEZETT GARANCIA NÉLKÜL, BELEÉRTVE TÖBBEK KÖZÖTT AZ ELADHATÓSÁGRA, EGY ADOTT CÉLRA VALÓ ALKALMASSÁGRA ÉS A JOGSÉRTÉS HIÁNYÁRA VONATKOZÓ GARANCIÁKAT. A SZERZŐK VAGY A SZERZŐI JOG TULAJDONOSAI SEMMILYEN ESETBEN SEM FELELŐSEK SEMMILYEN KÁRÉRT, KÁRTÉRÍTÉSÉRT VAGY MÁS KÖTELEZETTSÉGÉRT, AKÁR SZERZŐDÉSES, AKÁR JOGSÉRTÉSI, AKÁR MÁS JOGALAPON, AMELY A SZOFTVERBŐL, ANNAK HASZNÁLATÁBÓL VAGY MÁS, A SZOFTVERREL VÉGZETT TEVÉKENYSÉGBŐL ERED, ILLETVE AZZAL ÖSSZEFÜGG.

Gondold át, mely triggerekre van valóban szükség

Olvasd el a „Biztonsági megerősítés a GitHub Actionshöz” útmutatót

A fenti gyakorlatok korántsem teljes körűek. Ha átfogó útmutatót szeretnél a GitHub Actions biztonságos használatához kapcsolódó bevált biztonsági gyakorlatokról, nézd meg a GitHub biztonsági útmutatóját.

Workflow-ellenőrzőlista

A következő ellenőrzőlistával ellenőrizheted, hogy egy workflow követi-e a bevált gyakorlatokat. Az ellenőrzőlista nem a teljességre törekszik, hanem a legfontosabb elemekre összpontosít.

Másolható változat, például PR-ekhez

  1. kivéve, ha a nyelv az npm ökoszisztémát használja.