oke, emese, elolvastam. Tehat egy alkalmazas build-elese a feladat. Ennek reprodukalhatonak kell lennie. Ehhez pedig automatizalhatonak kell lennie. Amit te felvazoltal, az a kokany matyiskodas meg erre a use case-re is.
Irtam fentebb, de ugy latszik, neked 1x sem sikerult elolvasni (vagy esetleg a koncepciot nem ertetted), de egy alkalmazashoz altalaban OS-beli fuggosegek is tarsulnak. Ezert nagyon nem eleg az, hogy ha a repo frissul, majd akkor build-elsz. Hanem ha az OS megvaltozik alatta (biztonsagi frissitesek nalatok nem rulez?), akkor is build-elni kell, sot le kell tesztelni, hogy az igy ujrabuild-elt cucc meg mindig jol mukodik-e. Aztan ha lett egy uj verziod az app-bol (ami akkor is uj verzionak szamit, ha csak az OS, fuggosegek valtoztak meg alatta, es amit valahogy jelolni kell), akkor azt el kell tarolni valahogy.
Olyat meg biztos nem lattal, hogy a docker ugy meggajdul, hogy olyankor a /var/lib/docker-re kuldott ecetes rm -rf a megoldas. Ilyenkor mit csinalsz az eppen nem futo kontenereddel? Szoval a legjobb az, ha az egeszet egy ci pipeline-ra bizza az ember. Gondolom, te ilyet messzirol sem lattal, ezert batoritasz ugyetlen antipattern-t.
De kerdezheted, mi van akkor, ha a sokaig tart az (docker) image build-elese, mert sok cuccot bele kell tenni? En ezt ugy oldottam meg, hogy csinaltam egy koztes stage-et, amiben benne van minden fuggoseg, legyen a neve pl. myapp/stage1, es ebbe kerul bele az app, amit build-elni kell. A stage1-et meg inger szerint update-elem (pl. hetente, minden sec. fix eseten, whatever). Ja, tfh sokaig tart a stage1 elkeszitese: pont ez egy ujabb erv, hogy ne kezzel csinald, aztan malmozz, amig minden felmegy, hanem elindul mondjuk egy jenkins job, ami a vegen szol, hogy kesz.
Jo ez a forum, hogy olyanoktol is kerdezhetsz, akik tobbet lattak nalad, nem? ;-) Tetete nagyarc...