Refactor notes

doc/ci/docker/using_docker_build.md

@@ -67,7 +67,8 @@ GitLab Runner then executes build scripts as the `gitlab-runner` user.
 
 5. You can now use `docker` command and install `docker-compose` if needed.
 
-By adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions.
+Notes:
+* By adding `gitlab-runner` to `docker` group you are effectively granting `gitlab-runner` full root permissions.
 For more information please checkout [On Docker security: `docker` group considered harmful](https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful).
 
 ## 2. Use docker-in-docker executor
@@ -138,15 +139,16 @@ In order to do that, follow the steps:
       - docker run my-docker-image /script/to/run/tests
     ```
 
-By enabling `--docker-privileged` you are effectively disabling all
+Notes:
+* By enabling `--docker-privileged` you are effectively disabling all
 the security mechanisms of containers and exposing your host to privilege
 escalation which can lead to container breakout. For more information, check out the official Docker documentation on
 [Runtime privilege and Linux capabilities][docker-cap].
 
-Using docker-in-docker, each build is in a clean environment without the past
+* Using docker-in-docker, each build is in a clean environment without the past
 history. Concurrent builds work fine because every build get it's own instance of docker engine so they won't conflict with each other. But this also means builds can be slower because there's no caching of layers.
 
-By default `docker:dind` uses ``--storage-driver vfs` which is the slowest form
+* By default, `docker:dind` uses ``--storage-driver vfs` which is the slowest form
 offered.
 
 An example project using this approach can be found here: https://gitlab.com/gitlab-examples/docker.
@@ -207,15 +209,21 @@ In order to do that, follow the steps:
       - docker run my-docker-image /script/to/run/tests
     ```
 
-By sharing the docker daemon, you are effectively disabling all
+Notes:
+* By sharing the docker daemon, you are effectively disabling all
 the security mechanisms of containers and exposing your host to privilege
 escalation which can lead to container breakout. For example, if a project
 ran `docker rm -f $(docker ps -a -q)` it would remove the GitLab Runner
 containers.
 
-Also, concurrent builds may not work; if your tests
+* Concurrent builds may not work; if your tests
 create containers with specific names, they may conflict with each other.
 
+* Sharing files and directories from the source repo into containers may not
+work as expected since volume mounting is done in the context of the host
+machine, not the build container.
+e.g. `docker run --rm -t -i -v $(pwd)/src:/home/app/src test-image:latest run_app_tests`
+
 ## Using the GitLab Container Registry
 
 Once you've built a Docker image, you can push it up to the built-in [GitLab Container Registry](../../container_registry/README.md).