Szoftverfejlesztés során a git hook-okat

Programozás

Aki nem fejleszt vagy nem használ Gitet, ne szavazzon az egyszerűség kedvéért. Nemrég ráakadtam erre: composer-git-hooks , ez az apropója a szavazásnak. A Git hook-ok ugye lintelhetnek, kijavíthatnak egyszerűbb coding standard violation-öket, commit message-eket egységesíthetnek stb. A CI is tudja ezt, de akkor annyival nagyobb ott a zaj, a fejlesztő gépén már egy csomó mindent lehet ellenőrizni.

Kommentben megköszönöm, hogy ahol használatban van, miféle varázslatok történnek a hook-okban felétek.

Használom, szervezetileg egységesen be van állítva.
21% (94 szavazat)
Használom, saját megoldás van.
13% (59 szavazat)
Nem használom.
65% (289 szavazat)
Összes szavazat: 442

( Tassadar v | 2022. 02. 13., v – 09:04 )

Szerkesztve: 2022. 02. 13., v – 09:05

Nem, mert fejlesztői gépről minden esetben olyan [feature] branch-be commitolunk, ami törlésre kerül - CI-ben pedig transzparens a commit javitandó dolgai.

Lehet, de minek? A saját gépeden másodpercek alatt is lefutnak az ilyen hookok, cserébe a CI meg fókuszálhat az erőforrás igényesebb dolgokra. Mondhatnád, hogy "de hát a CI-ban ez ugyan annyi időt venne igénybe", de amikor van egy projected amin >1000 programozó dolgozik, akkor ezek a kis hookok nem csak sok erőforrást tudnak bezabálni, de sok időt is (executor lock).
Ez fölött szerintem minden programozótól elvárható, hogy valamilyen szinten tesztelje a saját kódját is mielőtt azt beküldené merge-re - ebből a szempontból ezen hookok futtatása tényleg az a minimális effort amit én minden fejlesztőtől elvárnék..

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Lehet, de minek? A saját gépeden másodpercek alatt is lefutnak az ilyen hookok

Kérlek, csak a magad nevében beszélj. Van olyan servicenk, aminek a tesljes integrációs tesztje 10-20+ perc és egy 20 GB-s image is kell a teszthez.

Hadd döntsem már el én, hogy akarom-e futtatni a tesztet a helyi gépen vagy sem. CI-n amúgy is kell, anélkül nem mehet a merge, hogy ott ne futna le (meg nincs approve a PR-en, stb.). Viszont sok esetben nincs szükségem arra, hogy lefuttassa nekem a teljes integrációs tesztet, mert olyan helyre nyúlok hozzá, amit már az unit tesztek is kihoznak (pl. bugfix) vagy azért, mert egyébként is felhúzom a környezetet a fejlesztéshez, és akkor bazi zavaró lenne, ha egy commit hook még ott nekem elkezdené felhúzni majd a végén lezúzni a teszt környezethez tartozó docker imageket.

A post-merge hookokat ne vedd ide.. A kérdés inkább azokra a hookokra vonatkozott amik még a commit pusholása előtt meghívódnak lokálisan (nálam ezekből van most kb 25 darab, 3 mp se kell, hogy lefussanak mielőtt a rebase/push megtörténik)

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

És? Nem is kell neki.. Ebben a scope-ban csak static checkerek (tipikusan linterek) vannak, amik egy nyamvadt compiler-t sem hívnak.. Run-time checker oda valóban nem való, azt tényleg csinálja inkább a CI

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Na jó, adok konkrét példákat:

Linters:
    # Ezeknél a logika tipikusan az, hogy a hook megvizsgálja, hogy a commitban milyen típusú file-ok változtak, majd arra ráhívja a megfelelő linter(eket)
    Ansible Lint (https://ansible-lint.readthedocs.io/en/latest/)
    bandit (https://github.com/PyCQA/bandit)
    flake8 (https://github.com/PyCQA/flake8)
    Jenkinsfile lint (házi script, ami Jenkins Development Tools-ra épít: https://www.jenkins.io/doc/book/pipeline/development/ )
    Hadolint (https://hadolint.github.io/hadolint/)
    pylint (https://pylint.org/)
    shellcheck (https://www.shellcheck.net/)
    Buildifier (Bazel projectekhez: https://github.com/bazelbuild/buildtools/tree/master/buildifier )
    gofmt (https://pkg.go.dev/cmd/gofmt)
    yamllint (https://github.com/adrienverge/yamllint)
    helm lint (https://github.com/helm/helm)
    pmd (https://pmd.github.io/ - tipikusan java projectekhez használjuk)
    Perlcritic (https://metacpan.org/dist/Perl-Critic/view/bin/perlcritic)
    Robot linter (https://github.com/boakley/robotframework-lint)
    
További checkek, formatter-ek)
    ClangFormat (https://clang.llvm.org/docs/ClangFormat.html)
    jsonnetfmt (https://github.com/google/jsonnet)
    Black (https://github.com/psf/black)
    Binary check (lehetőleg bináris file-t ne merge-eljünk be)
    Commit message check (van e Commit-ID a commit message-ben)
    CRLF check (sorvége karakterek legyenek egységesek)
    Whitespace checker (sor végén ne legyen whitespace, illetve tab/szóköz indentáció egységes legyen)
    Python version checker (házi script, sokan nem tudták Python2-őt elengedni)
    Restricted filenames checker (con/con ugyan vicces, de nem minden rendszer díjazza)
    Symbolic link checker (symlink lehet, de git repo-n kívülre nem mutathat, mert az erős security risk)

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Utóbbi..
Van több nagy monorepo, amikben több microservice-t is fejlesztünk (más-más nyelvekben: C++, Python, Go, Java), plusz a project specifikus infra automation is azokban lakik (IaaC - Jenkins, Ansible, belső scriptek (python, bash, perl)).
És míg a nagyobb projectek (monorepok) egymástól szeparáltan el tudnak lenni, a CI oldalt simán lehetett centralizálni, ezért is lett ennyi minden berángatva local hookokba is.
// Aminek egyik nagy előnye pont az volt, hogy amikor 1 project elkezd valami teljesen új dolgot (microservice) 0ról fejleszteni, akkor az esetleges új csapatnak megvan a lehetősége, hogy több nyelvből válogasson, és az azokhoz használható lintereket nyomban megkapja 0 befektetéssel

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

En a szemlelettel nem ertek egyet. Haromszor eltorik a branchen a CI es rajon, hogy jol felfogott sajat erdeke, hogy figyeljen a kodjara. Ettol fuggetlenul szive joga, hogy pre* hookokat allitson be, de nem jellemzo, inkabb az IDE-t pimpelik, hogy betegye a copyright headert, normalisan formazza a kodot stb. Ezernel joval tobb fejelsztorol beszelek.

Ha már el tudta törni a CI-t (mondjuk egy LF / CRLF beállítás miatt), akkor az már régen rossz.. Inkább az szokott lenni, hogy a fejlesztők szidják a CI-t, mint a bokrot, amikor X idő után adja a commitjukra a -1-et, aztán meg nekik kell megérteniük, hogy melyik job, melyik outputját (file / console) kell néznie, hogy lássa mi nem tetszik a CI-nak..

Ez viszont mind idő.. Betolni a jobot az executor queue-ba, megvárni amíg felszabadul egy executor, lefuttatni, feedbacket adni, megvárni amíg a fejlesztő ezt észre is veszi, aztán amíg utánamegy a hibának, és amíg javítja..
Localban megfuttatot hook esetén a feedback viszont szinte azonnali, és a fejlesztő közben nem mással (kávézás?) baxa el az idejét..
 

Az embert 2 éven át arra tanítják hogyan álljon meg a 2 lábán, és hogyan beszéljen... Aztán azt mondják neki: -"Ülj le és kuss legyen!"..

Ilyen alap problémákra mint CRLF stb szerintem jobb egy .editorconfig, akkor ott van a kodban is az elvart formatting.

Ertem amit mondasz, ti ugy szerettek dolgozni (vagy erre neveltetedk a fejlesztoket), de ez nalunk marginalis problema.

CI reszhez: build executor mindig van, mert dinamikusan skalazodik es ephemeral a build kornyezet, hogy biztosan idempotens legyen.

( RasTasi v | 2022. 02. 13., v – 10:48 )

ruby-hoz van egy overcommit nevű cucc, ami kiaknázza a git hook-okban rejlő lehetőséget, egy darabig node -os környezetben is ezt használtuk, aztán a javascript huszárok kieszközölték a husky -t. Summázva tehát: igen, használtom.

( belsodaniel | 2022. 02. 13., v – 11:36 )

A composer ki van hagyva ebbol, az IDE tudja azokat a (php cs fixer, phpmd), amik szuksegesek fejlesztesz kozben. A CI feladata az, hogy ezeket be is tartassa.

( Protezis | 2022. 02. 13., v – 12:39 )

Commit message ellenőrzésére, hogy pl. benne van-e a ticket number, teljesen ok. Minden másra ott van a CI, van pull request, van code review. A fejlesztői kultúra része kell legyen az (meg ideális esetben a builddé), hogy pull requestet már eleve úgy nyitunk, hogy a statikus kódelemző toolokat lefuttatuk előtte.

Egyébként meg mindenki azt rak be hooknak, amit akar, de ezeket standardizálni és előírni egy projekten, az baromság. Úgyse lehet betartatni.

( tornai | 2022. 02. 13., v – 14:56 )

Szerkesztve: 2022. 02. 13., v – 14:56

Kényszerítve vagyok-voltam a használatukra, de a pokol tüzére kéne vetni mindet.

azok leginkabb. juniornak adhat nemi tamaszt/tippet, masra nem jo. senior/expert szinten nem tud hozzaadni semmit a fejlesztonek (ha igen, az nem senior/expert szinten van), ellenben frankon akadalyoz, amikor okossagokkal bombaz.

nalunk is volt, egyhangu szavazassal kivagtuk a gitlab-ci.yaml -bol.

Akkor szarul van konfigurálva az analyzer. Én simán finomhangolom úgy, hogy amit gyakran elkövetek hibát figyelje, de ami tudom, hogy miért van, azt hagyja ki. Az első tíz futtatás agyzsibbasztó, de utána meg segít, hogy ha figyelmetlen voltam valahol, azért szóljon.

Tipikusan ilyeneket bökök el, hogy JSON-ban vessző, ERB template-ben if-else/do-end lezárások sorrendje, shellben régi berögződések... ezeknél nagyon hasznos. De igen, kell bele effortot tenni, hogy ne legyen útban, hanem hasznos legyen.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

( szalonna | 2022. 02. 13., v – 18:21 )

Frontend fejlesztőként eddig majdnem minden projekten használtuk az elmúlt pár évben, pl kódot előformáztuk, lokálisan lefuttattuk a lintert, illetve a céges copyright headert is beraktuk, de szerintem bőven használtuk ki a lehetőségeket. 

---
hack the planet

( tornai | 2022. 02. 13., v – 21:58 )

Szerkesztve: 2022. 02. 13., v – 21:58

-

( hunludvig v | 2022. 02. 14., h – 08:08 )

A kérdés csak kliens oldali hook-okra vonatkozik vagy minden git hook-ra?

( iattilagy | 2022. 02. 14., h – 08:43 )

Szervezetileg van néhány. Mondjuk csak szól, hogy gond van és tudod ignorálni, ha kell (pl. trailing whitespace check-et ignorálni kell patchfileokon.). Az, hogy belenyúljon a kódba szvsz hülye ötlet.

( kassaiviktor | 2022. 02. 14., h – 18:05 )

pl configok vannak vezetve gitben. bizonyos időközönként pull (=fetch+merge) van, itt egy post-merge hook van beállítva, hogy reloadolja a megfelelő service-eket

4 és fél éve csak vim-et használok. elsősorban azért, mert még nem jöttem rá, hogy kell kilépni belőle.

( dotnetlinux | 2022. 02. 25., p – 19:52 )

Szerkesztve: 2022. 02. 25., p – 19:53

Commit elott, kozben: forraskod lint check, project build (2.5s, TS microservice) es commit subject test. Husky.

Elsore zavart, 4 ora alatt megszoktam, azota tetszik. Ennyi idosen szeretek szabalykoveto lenni. 

( hrgy84 | 2022. 02. 27., v – 20:32 )

Én elkezdtem használni a pre-commit nevű projektet, és rohadt jó. Sok mindent kijavít futásidőben, RuboCop/CookStyle checkek, szól ha valamit elböktem. Unit/Integ teszteket nem itt futtatnék, azért fejlesztünk branchen, de a statik analizáció teljesen jó.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-