Expand CI_PROJECT_ID in docker volumes
What does this MR do?
When creating a build, some allowed environments are expanded. Now only CI_PROJECT_ID
is allowed. After expanding, we introduce dynamic host path for docker mounts.
Why was this MR needed?
With this feature, we can more safely share the build_dir
or cache_dir
by adding a project id in host path.
Runner seems to have three methods for volumes
a) host-bound path b) host-based cache volume c) docker cache volume.
All these three ways should have ability of project&concurrent level isolation. In addition in some scenes, b) and c) is not suitable, such as:
- for local disk part management, some in-container path have to binding to different host base paths, so b) is not suitable which always use [runner.docker.cache_dir] as based dir, and c) will consume docker graph storage which sometimes is too small
- admin does not want to create too many docker volumes, so [runner.docker.disable_cache] is always true, which will blocking both b) and c), whilst b) seems should not be disabled.
What's the best way to test this MR?
Create a docker runner, mount the build dir like this:
/path/to/builds/$CI_PROJECT_ID:/builds
Then, in the job view, one can only read/write the content of the same project with current job. In the mean time, the build dir is still shared with different runners/jobs for same projects. On the other side, in the host view, all the build dir will be in the patten:
/path/to/builds/<project-id>/<runner-short-id>/<concurrent-id>/<project-slug>
What are the relevant issue numbers?
Close #27181