GitLab 16

Byla vydána nová major verze 16 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.

23.5.2023 08:00 | Ladislav Hagara | Nová verze

Komentáře

[Max]

Podobná nálož novinek je v Gitlabu snad každý měsíc. Je to neskutečný, jak rychle se to rozvíjí a jak málo toho dokážou rozbíjet. Za nás vím snad jen o jednom bugu, co zavlekli s nějakou verzí.
Zdar Max

[plostenka]

GitLab je naprosto neskutecny bastl. 2.8 G v /opt staticky linkovaneho postgresu, perlu, ruby+rails, nginx... Nikdy vic.

Nastesti existuje Gitea, coz je ~30 M (o dva rady! mensi) reseni. A webxicht ma taky.

[Max]

To je ale docela silné nepochopení, co Gitlab je a jak funguje.
Když jsem ho viděl poprvé, tak jsem si také chvilku klepal na čelo, ale opak je pravdou. Mají Omnibus balíček, kde je všechno včetně db, redisu a dalších věcí. Celé se to nastavuje prostřednictvím jednoho konfiguračního souboru. Správa celého prostředí je strašně jednoduchá, než to provozovat v rámci OS v různých verzích.
Součástí je i Mattermost (open source obdoba Slacku). Naladíš Omnibus a máš kompletní all-in-one řešení na řízení velkého týmu a správu obrosvských projektů. Nároky na správu jsou pak nula nula nic ("apt-get dist-upgrade" se o vše postará, občas ti to jen napíše, aby jsi spustil příkaz na upgrade db na novější PGSQL a jede se dál).

Gitlab není jen správce gitu, ale je to i buildovací systém a kompletní CI/CD řešení s možností napojení na kubernetes. To znamená, že nepotřebuješ ani Jenkins apod. projekty. Prostě provedeš merge, spustí se pipeline (buď ručně, nebo automaticky na základě nějakých pravidel), projekt se ti vybuildí na runnerech a pak třeba automaticky nasadí do test prostředí, nebo produkce. Součástí mohou být automatizované kontroly na zranitelnosti, unit testy, kontrola kódu (např. pomocí sonarcube), kontrola nasazené app (třeba pomocí Selenium), v případě, že to neprojde testem, se udělá rollback atd.
Na kooperaci s teamem se pak může použít Mattermost, který má nastavení ověřování proti Gitlabu (ten zase může být pro AD apod.). Pod jedním přístupem (krytým třeba MFA) máš tedy dostupné vše.

Je to tedy o tom, zda chce člověk zůstat jen u verzování a nějaké správy zdrojových kódů, nebo zda chce i automatizovat a řešit co nejméně zbytečných overheadů při vývoji.
Proto pak existuje pozice DevOps, což je ta osoba, co ten proces nastavuje a píše onu automatizaci (pipeline) v kooperaci s vývojáři / projektovým managerem a s IT adminy.
Zdar Max

[plostenka]

Mají Omnibus balíček, kde je všechno včetně db, redisu a dalších věcí.

A Snap a buildeni ze zdrojaku. I v tom jejich repozitari je jen mega-omnibus, neexistuje "core" verze, nebo aspon moznost pouzit distribucni postgres/nginx/foo. Integrace GitLabu do existujiho serveru je "neresitelny problem". A trovne velke teamy, kde se tohle vyuzije, budou mit ruzne sluzby na dedikovanych strojich.

Celé se to nastavuje prostřednictvím jednoho konfiguračního souboru.

To je hezke u malych projektu, ale ten jejich konfigurak ma 10k+ radku. /etc/gitlab.conf.d/ anyone?

Je to tedy o tom, zda chce člověk zůstat jen u verzování a nějaké správy zdrojových kódů, nebo zda chce i automatizovat a řešit co nejméně...

Jasne, ale i tyhle reseni potrebuji modularitu. V konfigu se sice da leccos vypnout pres foo.enable, ale pak pulka veci nefunguje. A jsme zase u bodu 1), nahradit integrovanou komponentu distribucni/existujicim setupem nejde.

[Max]

Co se tedy řeší? Na jedné straně ti vadí, že to má 2,8GB, na druhé straně pak to, že nevíš jak nasizovat hw pro 20k uživatelů?
Je to komplexní konzistentní balíček, díky kterému dokážou zajistit přesné chování s minimálními nároky. Navíc je pak děsne easy údržba pro admina. Nevidím v tom žádný extra bastl.
Pokud chceš sizovat na větší počet uživatelů (myslím, že se opravdu někde psalo, že není problém s jednou instancí obsloužit až 20k uživatelů), tak kromě hw můžeš rozjet další instance, mít HA apod.
Jinak example konfiguráku má 3,3k řádků. Ani v tom nevidím žádný problém. Osobně nevidím rozdíl v hledání konfigurace v jednom souboru, nebo v deseti. Rozdělení do více částí vypadá opticky lépe, ale to je asi tak vše.
Každopádně Gitlab spravuji několik let, takže mi můžeš dál v klidu vysvětlovat, jak je to velký špatný :D
Zdar Max

[plostenka]

Na jedné straně ti vadí, že to má 2,8GB, na druhé straně pak to, že nevíš jak nasizovat hw pro 20k uživatelů?

Pocet uzivatelu neni dulezity. Co se pocita jsou transakce za sekundu. A tam, aspon pri mem pokusu, gitlab ziskal krasnou nulu.

Navíc je pak děsne easy údržba pro admina. Nevidím v tom žádný extra bastl.

To "desne easy" vypada tak, ze ani po mnoha hodinach konfigurovani nenajel integrovany supa-dupa-optimalizovany nginx na 8080 (vedle httpd na 80).

Osobně nevidím rozdíl v hledání konfigurace v jednom souboru, nebo v deseti.

Grepovani jiste. Ale specificke upravy a povoleni/zakazani neceho je mnohem jednodussi pres conf.d, nez pres (od)komentovavani bloku rozesetych po jednom centralnim souboru.

Každopádně Gitlab spravuji několik let, takže mi můžeš dál v klidu vysvětlovat, jak je to velký špatný :D

Uprimnou soustrast.

[Max]

To "desne easy" vypada tak, ze ani po mnoha hodinach konfigurovani nenajel integrovany supa-dupa-optimalizovany nginx na 8080 (vedle httpd na 80).

To spíše něco vypovídá o správci...

Uprimnou soustrast.

Jak už jsem psal, spravuji spokojeně několik let, nároky na správu téměř nula. Tou téměř nulou je myšleno to, že když vyjde nová verze, musím ručně spustit "ansible-playbook update-gitlab-runners.yaml"
Vše nakonfigurováno na vlastní doméně s vlastním cert (mattermost.corp.devaine.tld, gitlab.corp.devaine.tld, s3cache.corp.devaine.tld...)
Vzhledem k totální bezproblémovosti přemýšlím nad tím, že už se vykašlu i na ten poslední krok a nechám to na plné automatice s notifikací přes maily, že něco proběhlo.

Pocet uzivatelu neni dulezity. Co se pocita jsou transakce za sekundu.

Počet uživatelů, které dokáže řešení obhospodařit, je podle mě komplexní údaj, který vypovídá o celku jako takovém. Tj. skrývá se pod ní hafec testů různých transakcí. Každopádně nevím, co jsi měřil, ale opět, nesmyslně tu porovnáváš dvě řešení, které jsou rozdílné jako jabka a hrušky.

Já proti Gitea nic nemám, líbí se mi, ale absolutně mi uniká srovnávat ho s Gitlabem, Githubem apod. komplexními řešeními. Jasně, mají na webu i vlastní matrix na porovnání fcí, ale když na to koukám, tak porovnávají asi tak 1/100 toho, co třeba gitlab umí. Prostě si vyzobali jen to, co jejich řešení umí a pár drobků, které jakoby neumí.
Zdar Max

[plostenka]

Každopádně nevím, co jsi měřil, ale opět, nesmyslně tu porovnáváš dvě řešení, které jsou rozdílné jako jabka a hrušky.

Merim dve popularni reseni self-hosted git serveru s webovym rozhranim. Jedno se po instalaci z repozitare(!) nepodarilo behem x hodin ani rozbehat, druhe bylo, i bez repa, za pul hodinky nastavene a funkcni. Porovnani je to naprosto validni.

[Max]

Nebo to lze také chápat jako porovnávání schopnosti vašeho admina :). Každopádně pokud nepotřebujete fce, které Gitlab nabízí, tak nedává smysl jeho použití. My jsme začínali na svn, pak přešli na git a spravovali jej přes Gitolite. Pak jsme přešli na Gitlab a ve finále jsme začali řešit i automatizaci.
Každopádně je třeba i říci, že Gitlab-CE nemá moc dobrý reporting (chybí funkce v epics), takže projekt manager to nemá moc pohodlné, ale zase nechce EE verzi, že prý ho to zas tak moc nepálí. Tím chci říci, že na velké projekty a velké řízení je potřeba EE edice, bez ecpics nelze moc dobře sledovat práci a progress jednotlivých devíků a je třeba si vést částečně reporting bokem.
Zdar Max

[tttttttttttttt]

I v tom jejich repozitari je jen mega-omnibus, neexistuje "core" verze, nebo aspon moznost pouzit distribucni postgres/nginx/foo.

To není pravda, několik let jsem provozoval s postgresem/nginxem/redisem ze systému. A mají k tomu i oficiální návod.

Jasne, ale i tyhle reseni potrebuji modularitu. V konfigu se sice da leccos vypnout pres foo.enable, ale pak pulka veci nefunguje.

Mám jinou zkušenost, zatím jsem nenarazil na to, že by mi přestalo fungovat něco jiného než jsem v configu vypnul. Ale moc do hloubky jsem to nezkoušel.

[plostenka]

To není pravda, několik let jsem provozoval s postgresem/nginxem/redisem ze systému. A mají k tomu i oficiální návod.

To je to buildeni ze zdrojaku, o kterem pisu hned na zacatku. Jo, ve zdrojaku/v makefile uz si poladis leccos...

[Max]

Hele, to vypadá, že mluvíš o něčem, co jsi nikdy neviděl. Snad každou důležitou službu je možné nastavit v rámci globálního nastavení. Pokud chceš mít db někde mimo, můžeš si db v rámci dodávaného gitlabu zastavit / deaktivovat a v konfiguráku si definovat údaje pro externí db. Z toho jednoho místa se pak překonfigurují všechny služby, které jsou pod Gitlabem na onu externí db.
To samé pak platí i pro jiné služby. Tj. můžeš si nakonfigurovat externí redis, i který máš rozjetý v clusteru pod sentinelem apod.
Jenomže pak by jsi zase přišel s tím, že by jsi chtěl ten postgres dodávaný s Gitlabem odinstalovat (trápilo by tě, že ti na disku zabírá 300MiB navíc) atd.
Já si myslím, že to mají vymyšleno geniálně. Nepotřebuješ člověka, co rozumí redisu, jeho clusterování apod., nepotřebuješ člověka, co rozumí pgsql, nepotřebuješ člověka, co rozumí mattermostu. Prostě jen dáš apt-get install gitlab-ce, trochu upravíš jeden konfigurák a jedeš hafec let rollup aktualizace bez jediného problému.
Zdar Max

[kralyk z abclinuxu]

Jasne, ale i tyhle reseni potrebuji modularitu.

Ne, nepotřebují.

To, že nějaký software je nevimjakvelký monolitický blob se staticky nalinkovanými knihovnami, je v pořádku, resp. není to apriori špatně. To, že určitá sorta lidí proti tomu vede svatou válku je jejich problém. Pokud je někdo hardcore fanoušek byrokracie a uspokojuje ho představa X modulů a mezi nimi Y udržovaných verzovaných API, následně složité dependency DAGy v N*M distribucích*vydáních a BDSM hra s maintainery Debianu, kteří přijímají/odmítají balíčky podle toho, jakou má zrovna maintainer na přepážce náladu... tak prosim, asi ho to baví, proč ne. Ale bylo by fajn tohle nevnucovat za každou cenu ostatním.

GitLab je pro tebe zjevně zaměřeným zcela nevhodný, tak prostě použiješ Giteu nebo něco takového, a je vyřešeno. Já bych pro svoje vlastní potřeby nebo potřeby malého týmu GL taky nejspíš nepoužil, už kvůlil RoR. Nicméně v nejedné firmě posktyuje velmi dobrou službu.

[znalec]

Jak pise Max. Srovnavat Giteu s GitLabem je jako srovnavat pilnik s nozirskou dilnou

GitLab je produkt pro kompletni spravu softwaru. Planovani, vyvoj, udrzba, podpora, distribuce. Nepotrebujete ve firme nebo tymu nic jineho. Samozrejme, ruzne tymy maji ruzne potreby. Jeden tym si poridi GitLab, jiny tym si poridi ruzne nastroje. Oboji ma sve vyhody a nevyhody.

> 2.8 G v /opt staticky linkovaneho postgresu, perlu, ruby+rails, nginx...

Presne tahle se dodava stabilni komplexni software. U maleho nastroje si muzete dovolit ulepit deb, rpm, pkg a udrzet ho funkcni na vicero verzich vicero OS. Ale komplexni produkt integrujici mnoho produktu tretich stran? To byste se hledanim kompatibilnich sdilenych knihoven a opravovani chyb zblaznil. Staticky build je zdrojove efektivni reseni. Velikost instalace u tohoto software nebyla nikdy problem.

Nakonec podivejte se na alternativy klasickeho balickovani pro distribuce Linuxu. Slozitejsi produkty se lifruji staticky a instaluji Flatpackem nebo Snapcraftem...

[rpajik]

Komplexnost Gitlabu je samozřejmě velká, ale objektivně na hromadu projektů je gitlab naprosto zbytečný overkill, protože spoustu věcí gitea dnes už umí a neni to zdaleka jen webové klikátko ke git repo.

Buďme rádi, že si máme z čeho vybrat a na jednoduché projekty se nemusíme trápit s gitlabem a u složitých řešit nedostatek funkcionalit u projektů jako je gitea či gogs.

[Max]

To tu ale nikdo nezpochybňuje. Tady jde jen o to, že tu někdo nesmyslně oba projekty porovnává.
Zdar Max

[J]

Ja se zeptam jak se resi bezpecnost kdyz je vse v jednom konfiguraku? Obvykle chci mit oddeleny pristup pro DB cloveka, pro DevOps cloveka, pro web administratora, pro server administratora,…

[~]

To je DB Gitlabu ne projektu. Tam v podstate v zivote nesahnes.

[J]

Co DevOps? Co webserver admin?

[Max]

U nás je to tak, že system admin spravuje core infrastrukturu (stará se o to, aby gitlab běžel a patchuje ho). Na správu, patchování apod. Gitlabu není potřeba dbadmin. Zásahy do db se prostě nedělají, resp. nevím, k čemu, nenapadá mě žádný důvod.
DevOps zase nemá přístup na core infrastrukturu, ten řeší flow v rámci Gitlab rozhraní (psaní pipeline, procesů, deployment apod.). Na nic z toho nepotřebuje přímý přístup do OS.
V případě rozjíždění nějaké nové věci ze strany DevOps, se řeší kooperace se system adminem.
Vzhledem k tomu, že je to all-in-one a easy, tak webserver admin může kooperovat se system adminem při počátečním nastavení a pak už to může jít mimo něj a maximálně provádět jen vzdálené kontroly. Veškeré security změny a další věci se dodávají ze strany Gitlabu, takže toho ohledně konfigurace web serveru není moc potřeba.
Zdar Max

[J]

Super, dekuji za vysvetleni!

[Max]

Jinak my jsme ze začátku dali DevOps core přístup na runnery a kubernetí clustery, ale bylo to k ničemu. DevOps není system admin a nedával nic z toho. Nebavíme se o jednom, ale o více DevOps v řáde několika let. Nakonec to skončilo tak, že system admin nastudoval instalaci a správu kubernetího clusteru a DevOps pak měl přístup jen vzdálený přes kubectl, aby mohl upravovat nastavení, ale do systému se nehrabal. Podobně to dopadlo i s runnery, kde jeden DevOpsák za druhým vytvářeli boty. System admin tedy nastudoval, jak věci fungují a DevOps vlastně ani nespravuje runnery a opravdu už jen řeší samotnou konfiguraci kubernetu, deployment, psaní pipeline apod.
Nicméně i samotná konfigurace kubernetu je nad rámec DevOps a zdá se, že to bude muset převzít také někdo jiný. Ten řetězec se stále prodlužuje a lidí, kteří mají komplexní přehled, moc není.
Zdar Max

[J]

Ja tohle vnimam jako obrovsky pruser do budoucna. Ty reseni jsou jiz tak komplexni ze neni clovek ktery by vedel presne jak to funguje. V mem pripade mam firmu a mame par vyvojaru remote v US (bydlim v US, firma je v US). V ramci devops nasazuji reseni ktera jsou poorly documented, nikdo nema prehled jak to vlastne funguje a me jako vlastnika to neskutecne sere protoze nevim jestli to co dodavaji odpovida casu na tom stravenem. Pak jsme koupili dalsi firmu kde maji taky devops a to co produkuji nam za ty $$$ stalo ale kdyz vidim ze nikdo z toho tymu nevi jak se to vlastne buildi a nasazuje tak si rikam ze je to pruser ktery bude do budoucna stat x dalsich penez.

[Max]

Je to tak. Já tomu říkám výroba vlastního blackboxu. Dáváš prachy do vývoje, vývoj děláš, máš zdrojáky a vše okolo toho (i dokumentace vypadá, že je) a i tak je to blackbox. Tu část na backendu jsi schopný trochu pořešit tím, že nebudeš mít on-prem, ale použiješ kubernetes v aws apod. Jenomže i ten kubernetes, pipeline a další věci musí někdo nastavit, zdokumentovat a musí být někdo, kdo to umí i zkontrolovat. Najatý DevOpsák se skillem, doporučený velkou firmou zabývající se vývojem a dodávkami sw atd. a i tak trága, boty jak sviň atd.
Já jsem ve fázi, kdy podobné věci pozoruji z dálky, občas k něčemu přičichnu, ale snažím se od toho dávat ruce pryč (no time a ani chuť se v tom hnoji přehrabovat).
Zdar Max

[podlesh]

Tak jako vlastník s tím snad něco můžeš udělat, ne? Dokumentace není voodoo ani kvantová fyzika, je to jen práce kterou nikdo nechce dělat a nikdo nechce zaplatit. Když majitel řekne že do půl roku bude všechno zdokumentováno tak dobře, aby to náhodný konzultant zvládl nainstalovat a jinak budou padat hlavy... ono to půjde. Bude to stát Y peněz, ale to si holt musíš rozmyslet.

Samozřejmě, pokud "mám firmu" znamená "založil jsem firmu, vydal akcie a teď 80% vlastní investoři" tak se asi fakt nic dělat nedá.

[J]

Firmu vlastnim jako jediny vlastnik, zadne shares, zadni investori, zadne vojebavky. Ja jako vlastnik nemam sanci skontrolovat jestli je dokumentace dostatecna nebo ne, mohu tlacit leda tak na sefa tymu a samozrejme ze se snazi. Ono neni problem s instalaci, muzeme obnovit data ze zaloh, problem vidim v neznalosti celeho reseni, kazdy zna jenom kousek a kdyz potrebujes udelat neco vetsiho tak sedi na meetingu 6 lidi, kazdy neco vi a dohromady jsou schopni na neco odpovedet ale je to strasne neefektivni. 6 lidi na hodinovem meetingu me stoji treba $300-$400 a to je to co me sere. Mesicne se takhle projebou tisice a jelikoz to platim ja a ne nejaky investor tak me to samozrejme sere.

[zzz]

Naladíš Omnibus a máš kompletní all-in-one řešení na řízení velkého týmu a správu obrosvských projektů.

Mozna nejaky greenfield jo, ale pro existujici velke projekty toto neni pouzitelne (a vetsina velkych projektu uz je par let starych). U existujicich projektu uz mas existujici infrastrukturu, workflow, CI skripty. Vymenit jednu z tech komponent je problem, vymenit vsechny (za GitLab) je prakticky nemozne.

[Max]

Té poznámce nerozumím. Co je to prosím za argument? Resp. proč sem pleteš migraci z něčeho? To je přeci jasné, že pokud migruji z něčeho na něco jiného, tak musím zvážit všechny pro a proti (technickou náročnost, finanční apod.).
Jinak pokud jde o velké migrace, tak ty se snad nikdy nedělají formou hurá akce, ale migruje se komponenta po komponentně. A spousta velkých projektů se migrovala a migruje, tj. není nepřekonatelný problém migrovat třeba z Atlassianu na Github, případně jinak.
A to samé platí i pro Gitlab. To, že máš teď hned všechno k dispozici přeci neznamená, že musíš hned všechno zmigrovat. Proto jsou instalace, že třeba půlka věcí běží na Jira, další část na Gitlabu apod. Ty propojení / částečné replikace tam možné jsou. Ale nejde samozřejmě jen o ticket. Nevím, já bych podobné migrace tedy nezobecňoval.
Zdar Max
PS: php je podle tebe malý projekt, nebo velký projekt? Ti myslím migrovali ze self-hosted na Github. Balíčkovací systém Archu je podle tebe také malý projekt? Ti totiž postupně migrují na Gitlab (aktuálně repo, čeká je ticket systém a pak budou nejspíše pokračovat dál).

[zzz]

> Jinak pokud jde o velké migrace, tak ty se snad nikdy nedělají formou hurá akce, ale migruje se komponenta po komponentně.

Otazka je proc to vlastne delat. Ve velkych projektech trva migrace kazde takove komponenty mesice nebo treba i roky a potrebujes mit padne duvody proc to delat. To, ze integrovane reseni se snadnej konfiguruje a vse ma konzistentni UI nestaci. Pokud mas Jenkins a ten nejak funguje, tak bude docela tezke prodat migraci na GitLab CI s tim, ze to bude stat miliony za praci a pak jeste budes platit drazsi per person licenci.

php je podle tebe malý projekt, nebo velký projekt? Ti myslím migrovali ze self-hosted na Github. Balíčkovací systém Archu je podle tebe také malý projekt?

Open source nadsenci si radi pohraji s jejich CI, mne by spis zajimalo kolik velkych komercnich projektu zmigrovalo na GitLab.

[Max]

Hele, já s migracema nezačal. To ty jsi začal v duchu, že Gitlab nemá smysl, protože migrovat z čehokoli jiného by byl problém. Pokud bych přistoupil na tvou hru, tak znovu a naposledy, je to o tom, zda se to firmě vyplatí, což může posoudit jen ta firma samotná. Nemá smysl nad tím nějak spekulovat.
Každopádně dá se říci, že převod všech základních věcí (git, ticket, workflow, merge apod.) je celkem jednoduchá věc. Horší je případný přepis CI/CD a dalších věcí okolo. Osobně nevím o žádném komerčním projektu, co by migroval, ale to jen proto, protože vesměs se pozadím vývoje nijak nechlubí. Každopádně co vím, není to otrocký přepis, Gitlab, ale i jiné nástroje, podporují migrace / konverze z jiných projektů.
Navíc existuje i propojení Jenkinse s Gitlabem. Takže opět, nemusí se ani tato část migrovat celá najednou. Osobně jsem slyšel, že Jenkins je dost pozadu a Gitlab v posledních letech hodně nastartoval CI/CD. Pokud je to pravda, tak dřív, nebo později, musí nastat nějaký zlomový bod, který bude finančně / náročně vyrovnaný v poměru zůstání u Jenkinse vs migrace na něco jiného.
Jedna firma, co používala Jenkins, tvrdila, že s ním mají problémy. By default prý neumí všechno, honí se to pluginama, kde nastává šílený problém s údržbou (upgrade, nekompatibilita určité verze Jenkins a určité verze rozšíření atd.). Nevím, co je na tom pravdy, Jenkins neznám. Pokud je to ale pravda, tak to může být jeden z pádných důvodů, proč migrovat jinam. Osobně jsem se setkal se spousty projekty, co podporují rozšíření a v základu nemají plnou funkcionalitu. Vždy se o takových projektů řeší dependency hell. A čím více rozšíření, tím větší peklo. Platí to pro WP, Redmine, ale i spoustu dalších projektů.
Zdar Max

[xxx]

Problem Jenkinsu je, ze na zactku mas nejaky simple project, s par pluginama, vsechno funguje, konfigurace je citelna. Postupne to zacnes rozsirovat, a prakticky porad stojis pred dilematem, jestli napsat skript a ten volat, nebo pouzit nejaky plugin. A vlastne ani doted nevim, co je obecne preferovane reseni. Nakonec ti s pribyvajicim poctem pluginu zacne bobnat konfigurace. Prehlednost je uz davno nulova, a uz jen poznat, kde jsou nektere volby, ktere clovek kdysi nastavil je problem. Spousta veci se duplikuje, protoze nektere pluginy maji prekryvajici se pole pusobnosti. Cim dal tim vic se s ti nastaveni rozpada mezi projekty v Jenkinsu, a Jenkins file primo v projektu.

Ja nastesti v soucasne praci uz ten moloch potkavam jen okrajove, ale v minule praci jsem byl rad, ze jsem migtroval z Jenkinse do gitlab-ci. Ale byly to pomerne trivialni projekty. IMHO dneska ma s Jenkinsem cenu zacit, jen kdyz vis, kvuli cemu ho potrebujes.

[kralyk z abclinuxu]

Vymenit jednu z tech komponent je problem, vymenit vsechny (za GitLab) je prakticky nemozne.

Nikde není psáno, že musíš okmažitě od 1. dne zmigrovat vše, třeba pro začátek namigruješ pouze repa a bereš to postupně...

[j3nda]

+1 (gitea ~ zkusim, dik za tip)

[Dirka]

btw https://forgejo.org/faq/#why-was-forgejo-created

[_]

Super, přidali "Add emoji reactions on tasks, objectives and key results", to každý dobrý HTML/CSS kodér ocení.