Beforeexplainingtheavailableentrypointoverridemethods,let’sdescribehowtherunnerstarts.ItusesaDockerimageforthecontainersusedintheCI/CDjobs:
TooverridetheentrypointofaDockerimage,defineanemptyentrypointinthe.gitlab-ci.ymlfile,sotherunnerdoesnotstartauselessshelllayer.However,thatdoesnotworkforallDockerversions.
Let’sassumeyouhaveasuper/sql:experimentalimagewithaSQLdatabaseinit.Youwanttouseitasabaseimageforyourjobbecauseyouwanttoexecutesometestswiththisdatabasebinary.Let’salsoassumethatthisimageisconfiguredwith/usr/bin/super-sqlrunasanentrypoint.Whenthecontainerstartswithoutadditionaloptions,itrunsthedatabase’sprocess.Therunnerexpectsthattheimagehasnoentrypointorthattheentrypointispreparedtostartashellcommand.
WiththeextendedDockerconfigurationoptions,insteadof:
Youcannowdefineanentrypointinthe.gitlab-ci.ymlfile.
ForDocker17.06andlater:
image:name:super/sql:experimentalentrypoint:[""]ForDocker17.03andearlier:
image:name:super/sql:experimentalentrypoint:["/bin/sh","-c"]Defineimageandservicesinconfig.tomlLookforthe[runners.docker]section:
[runners.docker]image="ruby:latest"services=["mysql:latest","postgres:latest"]Theimageandservicesdefinedthiswayareaddedtoalljobsrunbythatrunner.
Toaccessprivatecontainerregistries,theGitLabRunnerprocesscanuse:
Todefinewhichoptionshouldbeused,therunnerprocessreadstheconfigurationinthisorder:
Therearetwoapproachesthatyoucantaketoaccessaprivateregistry.BothrequiresettingtheCI/CDvariableDOCKER_AUTH_CONFIGwithappropriateauthenticationinformation.