MUXX: ok, to mi asi staci a chapu :) dekuji ..

mimochodem, vsichni pouzivate embedded AS? my z nejakyho duvodu ne, toho se budu muset dopatrat, maji embedded nejake nevyhody? tipuju napriklad ze jsou mene konfigurovatelne?

tak php build muze bejt cela masinerie kroku - od composeru, pres vytvoreni pharu, az po operace nad frontend casti aplikace (vsechny ty gulpy, grunty a dalsi veci kterejm nerozumim)...

MUXX: coz znamena ze mate ve frontendovych zdrojacich pom.xml, ne?

a tomuhle asi porad nerozumim "Javova aplikace si pak stahne JAR a da si ho na classpath a dal s tim pracuje" .. chapu ze si na to jina javova aplikace udela maven dependency, takze se pri buildu pribali treba do waru .. ale neni mi jasny, jak se takhle pribaleny zdrojaky daji pouzit po deploymentu toho waru :)

MUXX: " js zabali do jaru a da do nexusu" .. takze vas JS je soucasti frontendu dane javove aplikace (tzn balite to do waru), nebo ho jenom zazipujes (a tak defakto vyrobis jar)?

a to 'da do nexusu' je pres

mvn deploy:deploy-file

, jako zpusob jak to nevolat pres Nexus REST api?

a uz vubec netusim, co myslis tim "java aplikace to pak pouzije jako zavislost" :)

URPUTNIK: npm repository mi dava smysl, ale vlastne nevim, co musi projekt splnovat, abych ho tam spravne nahral (kdyz koukam do node_modules, tak vypada kazdy trosku jinak .. ) .. tip na nejaky hezky navod?

ja potrebuju nekde drzet vysledek buildu, pro ruzne verze .. a staci mi vzdy jen nejnovejsi build pro danou verzi .. a ten vysledek buildu nebude mit zavislosti na nicem jinem, to je kompletni samonosna aplikace, nejak jsem cekal, ze npm zacne mit smysl, az kdybych mel zavislosti na neco dalsiho ..

MUXX: sypete vysledek js buildu do docker repository? jako vcetne celeho docker image? tam my jeste nejsme :) zatim mame jenom vysledek buildu ..

ad php - samozrejme nekompiluje, defakto je to jenom zazipovani konkretnich zdrojaku tak, aby to po rozbaleni na virtual s nastavenym apachem fungovalo

URPUTNIK: Docker? Npm? Php se nejak kompiluje?

URPUTNIK: gradle + artifactory? :)

mimochodem, pokud v ramci CI buildite nejavovy zdrojaky, do jakyho repozitare sypete vysledky, co se budou deployovat? ja je sypu do nexusu a vyrabim jim imaginarni pom, ale mozna existuje nejaky elegantnejsi zpusob :) jde mi o php, angular a react ..

URPUTNIK: tak je ma to tam co driv (jenkins/job/[job name]/config.xml), meli jsme nakopnuty FS a normalne tam mizely soubory ..

asi jsem slepej, kde ma prosim vas novejsi jenkins ulozeny konfigrace jednotlivych jobu? nachazim vsude jenom na priklady pres groovy/dsl verzi, tu my ale nepouzivame :/ a historicke jenkins/job/[jobnam]/config.xml neexistuje ..

URPUTNIK: Rekl bych, ze idealni bude nejaka stredni cesta :-)).

URPUTNIK: k tomu me napada, nemate nejaky oblibeny navod/video/priklad/skoleni na razeni/pipeline jobu v jenkinsu? videl jsem to jednou pres rameno pouzity, ale nikdy jsem to nenastavoval .. tak ze bych si mohl usetrit nejaky skrabani na hlave

a druhy, obecnejsi, dotaz - na strategii, osvedcuje se vam delat elementarnejsi joby, ktery se navzajem pousti, nez delat 1 velky?

historicky jsem napriklad meli maven job pro kazdy artefakt, ale byl v tom strasnej chaos, kdyz jsem zacali zvedat/tagovat jednolivy komponenty .. takze jsem to zjednodusili a napriklad cely workspace drzi jednu verzi, kdyz se dela branche, tak se dela branche vseho, takze 1 job na 'git brach' .. na druhou stranu mame taky checkout joby co pousti hotovy aplikace na server, ktery ale v sobe zase schovavaj ovladani tomcatu, jbosse, apache, apod .. uz je to dost neudrzitelny, tak se zas klonim k tomu, ze bych to rozpadnul :)

a do toho se nam blizi zavedeni virtualizace, coz treba bude znamenat vyrabet exekutory kdyz budou potreba ..

ahoj,
tahle diskuzni skupina mi unikla, sem budu chodit casteji :)

upgradovali jsme ted jenkinse (z 2.14 na 2.133) a tak nastavuju nejaky veci znova/poprve .. jeden z jobu, ktery mame, buildi frontendovy zdrojaky, nektere buildi webpack, nektere gulp .. kazdopadne, oba dva umi 'barevny' logy z buildu/testu/apod .. kdyz to poustim lokalne v konzoli, tak mi to funguje ..

na jenkinsu v logu jobu to bylo nejdriv uplne rozsypany, pac J neni defaultne v utf8 :) ale pridani -Dfile.encoding=UTF8 -jar ke spusteni to spravilo .. kazdopadne to barvy furt nema, prestoze jsem tam pridal aktualni ansicolor-plugin ..

ted to 'vypada' cernobile, napriklad:

[15:51:53] gulp-inject 7 files into youropinion/yourOpinion.translate.module.js.

kdyz v ramci buildu pustim navic bower/npm update, tak to dokonce udela tohle:

[15:25:56] gulp-inject 7 files into youropinion/yourOpinion.translate.module.js.

coz teda trosku vypada, ze se tam rozsypaly ty ansicolor tagy ..

takze, napada vas prosim, co dalsiho bych mohl/mel nastavit? mame tam i joby co delaj syntakticky kontroly (napriklad souboru s preklady), ktery bude cist netechnicky uzivatel, barvicky by mu mohly hodne pomoct :)

nedal jsem vedet, ale nakonec to facha, vlastne ani nevim proc to neslo :)

EDMAN_DORT: na nektere veci pouzivame, ale pro deploy hlavni aplikace chceme aby se to provedlo na identicke masine (instalaci ne vykonem) jako je na produkci... hlavne testy, v minulosti se jiz stalo, ze mel vyvojar jinou kompilaci php, kde to behalo, ale na produkci fail... to si nemuzem moc dovolit a blbe se to hleda pak

SADY: My sme presli z Bamboo na Bitbucket Pipelines (a tim zustali u Atlassian) a jsme vic nez spokojeni, to reseni vam nevyhovovalo?