Skript pre sledovanie zmien v lokálnych GIT repozitároch

10.7.2012 22:45 | Přečteno: 997× | Linux | poslední úprava: 11.7.2012 07:26

V súčasnom zamestnaní pracujem ako hlavný vývojár / integračný manager. Táto úloha si vyžaduje sledovanie zmien vo verejných repozitároch členov tímu. Rovnako ako väčšina linuxákov nemám moc v láske periodické opakovanie určitých úkonov (napríklad sledovanie zmien v repozitároch). Preto som si na tento účel napísal malý skriptík.

Než sa pustím do samotného popisu skriptu napíšem zopár slov o našom pracovnom postupe so systémom GIT.

Ako som už na začiatku spomínal moja rola (okrem developera) je integračný manager. Pri rozdelení úloh na manažéra a vývojárov má každý vývojár vlastný repozitár. Každý vývojár môže svoj repozitár aktualizovať z hlavného repozitára, ku ktorému má read-only prístup.

Ja som v tíme najskúsenejší a preto som priamo zodpovedný za kvalitu finálneho produktu. Aby sa do hlavného repozitára nedostali nedorobky kontrolujem každý commit pred jeho pretiahnutím do hlavného repozitára. V prípade, že nájdem nedostatky nechám chybný kód prerobiť a zaradím až bude napísaný v požadovanej kvalite.

Tento postup vyžaduje buď periodickú kontrolu obsahu repozitárov, alebo nejaký systém notifikácií napr.

kričanie

Rýchle, interaktívne, ale ruší to ostatných.

Gitlab

Gitlab je doslova kópiou github-u s integrovaným systémom na správu pull requestov. Žiaľ na rozdiel od jednoduchého commitu je prihlasovanie sa do webovej aplikácie a klikanie na pull časovo nehospodárne.

maily

Teoreticky v prípade ak by sa systém pekne integroval do mailového klienta bolo by to super. Každý však používa iného klienta, vytvorenie integrovaného systému by bolo pekne časovo náročné.

Git-watcher

Aby som maximálne eliminoval nedostatky rôznych systémov notifikácií rozhodol som sa napísať malý skript, ktorý bude perfektne prispôsobený nášmu pracovnému postupu.

Tento skript je napísaný v pythone 3. Aby mohol fungovať musí byť nainštalovaná knižnica pyinotify (hádam sa neznížim k takým hrúzam ako je pooling). Ďalej musí byť v $PATH nainštalovaný git a notify-send.

Pred prvým spustením sa musí skript nakonfigurovať. Akosi som v poslednej dobe lenivý, takže neošetroval som vôbec prípady kedy by konfiguračný súbor neexistoval. Bez neho jednoducho aplikácia skončí na výnimke.

Predvolená cesta ku konfiguračnému súboru je ~/.config/LinuxOS.sk/gitwatcher.cfg. Ukážkový konfiguračný súbor vyzerá nasledovne:

[DEFAULT]
icon=/usr/share/icons/oxygen/64x64/actions/svn-commit.png
color_add=#00ff00
color_remove=#ff2000
display_time=360000

[test]
directory=/home/user/gittest/.git

[test2]
directory=/home/user/gittest2/.git

Direktívy v sekcii DEFAULT sú voliteľné. Nasledujú už len definície samotných sledovaných repozitárov.

Po commite v niektorom zo sledovaných adresárov sa na systéme s podporou libnotify zobrazí pasívna notifikácia.

       

Obrázky

Komentáře

[Josef Kufner]

• gitweb + RSS čtečka: gitweb umí export historie do RSS a je součástí Gitu (je v každé distribuci). RSS čtečku není problém sehnat snad nikde. Navíc webové rozhraní usnadňuje zkoumání, co je v kterém repositáři nového.
• Post recive hook: Při vytvoření git repositáře je v .git/hooks vytvořen ukázkový hook, který posílá mail při nahrání nové sady commitů do repositáře. Stačí nastavit adresy a přejmenovat jeden soubor.

[podlesh]

My na to používáme workflow v JIRA. Když někdo nějaké issue dokončí, vyplní hash do speciálního políčka.

Já pak mám script který mi stahne z jiry všechny issue, najde do které repository hashe patří a vygeneruje mi seznam co už je a co není zamergováno.

[mirec]

Na takéto veci mám nakonfigurované redmine aj s automatickým uzatváraním ticketov (stačí v commite closes #123), ale zatiaľ to nikto v práci nepoužíva. Ticketovací systém by so rád v práci zaviedol, ale žiaľ nie je to tak jednoduchá záležitosť ako sa zdá. Takže zatiaľ tieto veci riešime chaotickým spôsobom bez riadenia.

[podlesh]

Na takéto veci mám nakonfigurované redmine aj s automatickým uzatváraním ticketov (stačí v commite closes #123)

Jo, tohle je pěkná vychytávka, ale bohužel ji lze použít jen u jednodušších (a dobře navržených) systémů kde se snadno ověří že je to opravdu hotovo a funkční. Když je mezi commitem a uzavřením prodleva hodiny až dny (build, nasazení, příprava dat, provedení testu, kontrola všech dvaceti míst v třech různých aplikacích které to může ovlivnit, navíc to otestování by měl dělat někdo jiný nezaujatý a právě teď jako na potvoru nikdo nemá čas) tak už to zas takový šlágr není.

Ticketovací systém by so rád v práci zaviedol, ale žiaľ nie je to tak jednoduchá záležitosť ako sa zdá. Takže zatiaľ tieto veci riešime chaotickým spôsobom bez riadenia.

To bych neřekl, když tam máte integrátora - to je samo o sobě velmi efektivní způsob organizace. V některých ohledech lepší než ticketovací systém.

Jinak stačí počkat až pojedeš na delší dovolenou a stane se průser

[Josef Kufner]

A nestačí, aby "closes #123" v commitu označilo ticket jako hotový (vyřešený), ale nechalo na nějakém člověku, aby ho doopravdy uzavřel? Mohlo by to tak automaticky sestavovat testerům seznam věcí k otestování.

[mirec]

Closes nastaví stav na resolved, uzatvoriť to musí ručne osoba zodpovedná za testovanie. Ten redmine nie je tak blbý ako vyzerá ;)

[dementni.lojzik]

presne to AFAIK JIRA ma - vyvojar nastavi na "closed" (napr. prave pres post hook commitu) a pak je na QA aby to otestovali na nastavili na "resolved"

[mirec]

Nie je to náhodou v JIRA opačne (tj. resolved nastavuje vývojár a closed QA)?

[m-a]

Zalezi od toho, ako je definovany "workflow" - postupnost stavov. Standardne je najprv Resolved, potom Closed.

[dementni.lojzik]

jo, sorry, prehodil jsem to, je to tak...

[mirec]

Jinak stačí počkat až pojedeš na delší dovolenou a stane se průser

Ja sa ako pravý workoholik na žiadnu nechystám. Voľno budeme mať v rovnakom čase, ja ostávam vtedy v pohotovosti keby niečo. Našťastie bývam v krásnom prostredí, takže budú pekné výlety do okolia s mobilom vo vrecku.

[sidik]

Já bych rád změnil politiku verzování právě v tomhle směru. Aktuálně jsou repa pro všechny týmy zapisovatelný a vzhledem k tomu, že všichni dodržují předepsaný systém, tak to nijak zvlᚍ nevadí. Nicméně bych rád zavedl centrální repo, kam by mohl zapisovat jen správce a dovnitř by pouštěl opravdu jen hotový a otestovaný kód.

Jak se u Gitu tohle řeší? Nějaké samostatné read-only repo, kam se ručně tahá kód z vývojového nebo je git schopen si tohle šéfovat na úrovni jednoho repozitáře? Nejradši bych totiž viděl jedno repo, ve kterém je branch stable a do něj může z ostatních branchů zařazovat jen admin (resp commit může poslat kdokoliv ale ten zůstane viset ve frontě dokud než admin schválí/zamítne).

[Josef Kufner]

Pokud naserveru použiješ např. gitolite, tak lze omezovat přístup na úrovni jednotlivých větví. Jinak v Gitu je z uživatelského pohledu celkem jedno, jestli je to větev nebo samostatný repositář – je to prakticky stejně pohodlné.