Davate prednost psani J. Pipelines v Groovy nebo radeji pouzijete "Bash" scripty?
Jake je vyhoda Groovy v tomto kontextu?
dávám přednost bash, ale blbě se automaticky analyzuje, na to je groovy lepší. Největší úlet je ale Jenkins se scripty v bash.
Každopádně, když si ten bash dobře strukturuješ, můžeš tam ledacos dobře implementovat a mít tam určitou možnost automatické kontroly.
90% kazdej pipeliny v groovy. Jednak podpora IDE (InteliJ Idea a importnuty konfig z jenkinsu), jednak moznost testovat pipelinu za pomoci nejakeho frameworku (obcas sa zide) a jednak dostupnost informacii o builde (moznost lahko dat daco do description, vyuzit nejaky plugin na ohviezdickovanie buildov / badge, ci moznost jednoducheho paralelizmu, kedy build dokumentacie a vykonavanie testov moze bezat paralelne a je to (subjektivne) strukturovanejsie zapisane ako v bashi). V neposlednom rade juniori maju skor skusenost s groovy, ako s bashom a naucit dakoho ako escapovat v sheli nie je celkom jednoduche :)
PS: Na druhej strane, ked je to v bashi (idealne kompatibilne s /bin/sh vseobecne), tak si clovek spusti "pipeline" aj u seba a vie to lokalne debugovat, bez nutnosti mat pristup na jenkins stroj.
to je také důležitý argument, groovy je dobře přenosné v týmu, má ucelenou dokumentaci a je to robustnější nástroj. Psát správně bash je strašně těžké, je potřeba opravdu dobrá zkušenost a jeho znalost, jinak hrozí chyby, problémy. To řikám jako někdo, kdo v bash píše denně.
Citace od: luvar kdy 01. 03. 2021, 19:51:04
90% kazdej pipeliny v groovy. Jednak podpora IDE (InteliJ Idea a importnuty konfig z jenkinsu), jednak moznost testovat pipelinu za pomoci nejakeho frameworku (obcas sa zide) a jednak dostupnost informacii o builde (moznost lahko dat daco do description, vyuzit nejaky plugin na ohviezdickovanie buildov / badge, ci moznost jednoducheho paralelizmu, kedy build dokumentacie a vykonavanie testov moze bezat paralelne a je to (subjektivne) strukturovanejsie zapisane ako v bashi). V neposlednom rade juniori maju skor skusenost s groovy, ako s bashom a naucit dakoho ako escapovat v sheli nie je celkom jednoduche :)
PS: Na druhej strane, ked je to v bashi (idealne kompatibilne s /bin/sh vseobecne), tak si clovek spusti "pipeline" aj u seba a vie to lokalne debugovat, bez nutnosti mat pristup na jenkins stroj.
To je přesně ta hranice, kterou mám pro sebe.
Groovy používám v Jenkins, pokud to bude jen v Jenkins. Například zobrazit seznam větví z git repo a dát uživateli vybrat, která se má buildit.
Bash - provádění tasku. Instalace aplikace etc. Důvod použití Bash je, že si nastavím env na dev stroji tak, abych to mohl spustit ručně a mám vše v gitu s projektem, takže každá větev může mít trochu jiný build. To se taky někdy hodí.
Ideálně to mít poskládané tak, aby se případně dalo lehce změnit build server. To jest groovy jen pro jenkins specifické věci a jinak pouštět skripty v gitu. Např. javě se snažím aby všechny ty skripty začínaly "mvnw..." nebo "gradlew..." protože většina vývojařů v čr používá windows