FSF k podmínkám používání GitHubu

Před dvěma týdny GitHub aktualizoval podmínky používaní poskytovaných služeb (GitHub Terms of Service). Nadace pro svobodný software (FSF) provedla jejich analýzu: podmínky GitHubu nejsou nekompatibilní s copyleftem, dle etických kritérií hodnocení softwarových repozitářů je ale GitHub hodnocen známkou F.

15.3.2017 17:22 | Ladislav Hagara | Komunita

Komentáře

[Jendа]

Takže GitHub má nové ToS. Došlo i ke změně té nejhorší části (pro srovnání takhle to vypadalo předtím). Nově to tam není na plnou hubu, ale je tam místo toho formulace, u které mi není jasné, co vlastně říká…

[pc2005]

Tak v případě sporu to stačí z githubu přesunout jinam ne?

[Josef Kufner]

To nemusí být až tak jednoduché, protože issues a pull requesty, které dělají z hromádky kódu projekt.

[pc2005]

Aha OK.

[trololo] Tak snad každej má všechny issues už vyřešený a commitlý opravy do gitu ne? [/trololo]

[Sid]

Mozno pre hello word super project. Realne predsa sa nefixuje kazda chyba hned takze hocijaky vacsi projekt ma kludne 1000 issues a tomu casto aj odpovedajuci pocet pull requestov.

[Vykook]

Koukám, že se dají najít nějaký skripty( např https://gist.github.com/unbracketed/3380407 ), ale nevím jak moc to funguje, nezkoušel jsem to. Já osobně razím cestu gogs.io na vlastní VPS. Narozdíl od gitlabu to utáhne i HW z kávovaru na kapsle a ve finále ta VPS s hromadou dalších věcí nevyjde o moc dráž, než github s privátníma repozitářema.

[Kate]

To vypadá hezky :) Jak je na tom s integrací různých CI řešení?

[Vykook]

Nevim, nejspíš nějak. Na "takové to domácí repozitářování" to nepotřebuju

Narazil jsem na nějaké https://github.com/drone/drone , ale jaká je funkčnost fakt netuším.

[Josef Kufner]

Na "takové to domácí repozitářování" to nepotřebuju 

No… zrovna CI je i na „domácím repozitářováním“ velmi užitečné. Najde se dost věcí, které jsou nějak nasazené, a je otrava po nějaké pozdější opravě zjišťovat, kam a jak se to vlastně tehdy nahrávalo. I jednoduchý deploy skript v CI toto řeší velmi elegantně a docela bezstarostně.

[Kate]

Asi tak… Přes Gitlab-CI mám řešený deploy už jednoho svého domácího projektu a brzo na to převedu další. Update pyenvu, databáze, testy, nasazení… Prostě dám push a nemusím se starat, za chvilku mi jede na webu nasazená beta / rc / produkční verze, v případě produkce ještě podmíněná ručním potvrzením před deployem.

[xkucf03]

Najde se dost věcí, které jsou nějak nasazené, a je otrava po nějaké pozdější opravě zjišťovat, kam a jak se to vlastně tehdy nahrávalo.

Tohle řeším lokálním (a rovněž verzovaným skriptem), který akorát pustím¹ – a nepotřebuji na to žádné CI ani další server. CI má smysl hlavně při práci v týmu a u větších systémů, kde vývojář často dělá změnu jen v malé komponentě² a pak je potřeba ověřit, že ta změněná komponenta nerozbila větší celek.

Navíc nepovažuji za šťastné používat CI na produkci – ta by měla být oddělená od testů/vývoje a mělo by dojít k vydání artefaktů označených číslem verze a jejich předání³. (jasně, týká se to trochu serióznějšího vývoje – na hodně místech se to různě bastlí a taky jim to nějak funguje, aspoň občas nebo nakonec).

_{[1] umí nasadit na test i na produkci
[2] a zkouší si tu nebo pustí jen jednotkové testy
[3] tzn. ideálně i personálně oddělené}

[unicode]

CI má smysl i při práci jednotlivce. Kdo nepoužívá, nepochopí, kdo používá, už se bez toho neobejde.

[xkucf03]

Tam mě napadá jediný přínos – ověří se, že ve verzovacím systému je všechno (ale i tohle si můžu ověřit sám tím, že udělám klon vedle a přeložím si to tam).

Jinak si ale můžu pustit všechny nástroje sám lokálně – a výhoda je v tom, že běží i nad rozpracovaným programem – kdežto CI normálně běží až nad tím, co bylo zaverzované.

[Conscript89]

Vsak k tomu jsou branche.

[Josef Kufner]

Gitlab CI používáskript pojmenovaný .gitlab-ci.yml (je to prostý soubor commitnutý spolu se zbytekem projektu), kde vedle příkazů je i napsáno kdy a na čem se mají spouštět, kde je výsledek buildu a co se má kešovat. Pro různé větve můžeš mít různá pravidla. Produkční verze může vyžadovat ruční spuštění deploye (na webu je pak čudlík, build ale může vyrobit artefakt automaticky) a podobně. Také to umí automaticky vytvářet testovací prostředí (Kubernetes) pro feature branche. Vedle samotného buildu si to také pamatuje, které verze byly deploynuté a kam, takže je k dispozici záznam a u každého řádku čudlík "Rollback".

[Vykook]

Pro většinu věcí, který se někdy někam pokouším deployovat mám Dockerfile, který to také z mého pohledu řeší vcelku elegantně a bezstarostně

[Jendа]

Ne, tím se nezbavíš odpovědnosti za „škody“, které jsi jim už „způsobil“.