You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
2. at times, there will be platform-dependent dependencies, and then it doesn't make sense to mount the whole repo (you'll need to make nuke deps build inside docker, and then once again outside docker, when finished). You might be good to go mounting the repo/.git folder instead of running git checkout . inside docker. This way, still have access to the whole git history, but you have a separate checkout instance
3. proxy variables likes AWS_* or GH_TOKEN from the host to the docker container
4. make docker-ci needs to be followed by a ./.ci.sh before_install to install required system dependencies, plus it can take a long time to create GIDs and do recursive chown, etc so ideally there would be a make docker-ci/scratch and make docker-ci where the latter would actually make use of an existing local image based on SF_DOCKER_CI_IMAGE + GIDs/etc + ./.ci.sh before_install
:cachedmake nuke deps buildinside docker, and then once again outside docker, when finished). You might be good to go mounting therepo/.gitfolder instead of runninggit checkout .inside docker. This way, still have access to the whole git history, but you have a separate checkout instanceAWS_*orGH_TOKENfrom the host to the docker containermake docker-cineeds to be followed by a./.ci.sh before_installto install required system dependencies, plus it can take a long time to create GIDs and do recursive chown, etc so ideally there would be amake docker-ci/scratchandmake docker-ciwhere the latter would actually make use of an existing local image based on SF_DOCKER_CI_IMAGE + GIDs/etc +./.ci.sh before_installcc Simon Schlegel (@spschlegel)
cc Fredrik Öhrström (@weetmuts) no 4 would be the intermediary step for creating repo-based docker images