RAGNAROK: Proc to potrebujes? Tohle je trochu zvlastni a nezda se mi, ze zrovna build je spravna faze. To by melo byt spis pri run, jestli chces aktualniho uzivatele. V buildu to vytvori jednoho uzivatele, ale spustit to pak muze nekdo jiny.
Dal bych do run, v containeru mel bash script, ktery prida uzivatele predaneho v run a bude pro aktualniho uzivatele v povolenych sudo commands. Ale spis proc to potrebujes? Mozna se najde lepsi reseni

RAGNAROK: v dockerfile si vytvoris jednoduse

ARG MY_USER
ARG MY_UID
RUN useradd $MY_UID $MY_USER

a v behem buildu mu je predas:

$ docker build --build-arg MY_UID=1234 --build-arg MY_USER=me . 

REFLEX: Jestli bylo chciple vsechno, hledal bych na serveru. Co uptime? Kouknul bych na posledni instalovane balicky, jestli tam nebyl docker/kernel/.... pripadne bych kouknul i do logu syslog/messages/apod.
Necekam ze kazdy container se exitnul ve stejnou chvili a bylo by to "chybou" toho co v tom bezi.

REFLEX: Nabidnu jeste za mne lepsi reseni. Co takhle to schedulovani resit uz na hostu? Pokud pouzivas kubernetes (da se pouzit i s docker-compose), tak je tam primo command schelule (cron line). Pak pouzijes php image a jen zmenis command. Pokud mas jen docker compose a uvnitr cisty docker, tak koukni na https://strm.sh/post/cron-tasks-inside-docker/ . Predpokladam ze container je udelan jako dind. Pokud by si bindoval nektere zarizeni ze serveru, mohlo by to byt tezsi, ale to nejspis nedelas. Nevim o tom, ze by primo vanila docker mel moznost schedulovani.

ADM: Neni nejlepsi. Je spatna z pohledu dockeru, kde by mela bezet maximalne jedna sluzba v containeru. Ale pokud nepotrebuje vystup logu a healthcheck na cron, da se to pouzit. Oddeleni ma jak jsem psal minimalne vyhovu v tom ze se to da skalovat.
Jina vec je, ze docker image byl mel byt asi dost jiny. Nepotrebuju v nem php-fpm. Nemusim potrebovat nektere knihovny a teoreticky i php kod muze pro cron byt uplne jiny nez pro web aplikaci (assets, presentery,...). Plus cron muze spoustet i jine procesy nez php (java, python,...). Ale to bez znalosti projektu nelze odhadnout.
Ale pokud, tak bych to komplet oddelil, klidne mel base image ktery ma pouze php a knihovny co budu potrebovat a pak jeden s php-cli a druhy s php-fpm a daval do nich ty soubory, ktere potrebuju.

REFLEX: Radsi dva containery. skalovani, omezeni resources (cron nebude potrebovat tolik co navstevovany web), nejspise jiny network,....
Zalezi co ten cron ma taky volat. Nejaky php script z aplikacniho kodu? Pro jednoduchost muzes udelat ty dva entrypointy jak pise ADM. Pokud cron bude delat vic veci a potrebovat i jine balicky, vlastni image.

REFLEX: pridas cron do cointaneru s php, a spustis ho jako samostatny container s jinym entrypointem crond (tzn. mas porad jednu docker image ve ktery je php i crond, a spustis je s ruznymi entrypointy)

MLEKAR_STEIN: Predavani mezi jobama je tam taky, je na to trigger plugin. Ale je to teda ze musis triggerovat z jednoho jobu. Ne ze jeden bezi kazdy den a o vikendu chci spustit jiny job, ktery vezme parametry z jineho posledniho buildu. Ale zase jenkins ma hezke a jednoduche api, takze by se slo zeptat na latest build a vytahnout si parametry.
Nebo... spustit trigger a mit at se spustenim ceka na vikend.
Pokud jsem dobre pochopil problem.
Mame treba projekt kde je asi 20 microservice. Kazda ma svuj CI. Jednou denne se spousti e2e testy. Vezmou se posledni buildute verze, kde vse proslo spravne. To se nasadi pres openshift na testovaci prostredi, spusti se testy. Kdyz je vse ok tak se otaguje ze tahle kombinace se muze nasadit.
Klidne napis do posty, kdyby si chtel. Treba by me napadlo reseni, pokud si na jenkins nezanevrel :) A pokud to neumi, tak groovy script by tohle zvladnul, kdyz ne, tak vlastni plugin :)

MLEKAR_STEIN: Ad jenkins: posouvani artifactu je bez problemu. Pokud je to v jednom containeru, tak samo od sebe. Pokud na kazdy step je jiny container, tak staci jen oznacit ktere soubory jsou artefactem. Nemusis resit nic sdileneho.
Jenkins pro stepy podporuje i spusteni treba od pulky. Takze pokud na zacatku mas build, pak testy atd. Tak muzes priste buildnout treba jen posledni step a vzit jaky byl stav z posledniho buildovani.
Jenkins je urcite slozitejsi, ale taky toho umi mnohem vic a da se mnohem lip rozsirovat, pokud je potreba.
Vlastne ani nevim, jestli gitlab umi treba matrix buildovani, coz ne kazdy oceni, ale muze se hodit treba na e2e testy.
Za mne velka vyhoda jenkinsu je taky v tom, ze je mu jedno kde je repository. Pokud se naucim gitlabci a pristi projekt bude na necem jinem, tak s tim nic neudelam.