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
And when building the image: docker build . --build-arg BASE_IMAGE_PATH=custom/path
Use cases 1: Relevant code is spread across multiple repos and all of those are checked out next to each other (in $(cwd)) before building the image, e.g.
$(cwd)/repo_1/
$(cwd)/repo_2/
$(cwd)/repo_3/
Dockerfile is located in one of these repos, but as we need content from all 3 repos, we're setting build context to $(cwd). This further means that we need to use the checkout name when specifying path for INCLUDE+, e.g. repo_2/path/to/base. So we have a hard-coded path that depends not only on the structure of the current repo (which is normal) but also on the name of the checkout (which doesn't have to match the repo name). This is not so bad from e.g. pipeline definition perspective (as it may also contain hard-coded checkout repo name), but it's not very convenient when engineers are configuring their local dev setup and need to make sure they follow expected naming convention when checking out relevant repos.
Use case 2: Having the included path configurable via ARG would allow different Dockerfiles to be used as a base image. For example, when launching the setup locally, we'd like to import base Dockerfile and build the final image (in our case, testing image) in a single command (for simplicity). On the other hand, when building the image in some pipeline, we'd like to use another, dummy Dockerfile which just says FROM base_image:latest (where referenced image is pre-built), because pipeline is defined in code and it's not a problem to build image with 2 commands (one for the base one and one for the final//testing one). However, that approach would ensure we're exactly (re)using the pre-built base image to generate the final/testing one to execute tests - we're not rebuilding it from the scratch, which would (theoretically) make it not to be 100% based on the base image (which we'll use in production).
The text was updated successfully, but these errors were encountered:
mandrije
changed the title
Support for build ARGs
Enhancement Request: Support for build ARGs
Mar 17, 2022
failed to solve with frontend dockerfile.v0: failed to solve with frontend gateway.v0: rpc error: code = Code(128) desc = Could not read file " build/src/$ENV/Dockerfile". Remember that the file path is relative to the build context, not the Dockerfile path.
Would be nice to support build ARG (if possible), which would allow included Dockerfile path to be passed on via build ARG, e.g.
Dockerfile content
And when building the image:
docker build . --build-arg BASE_IMAGE_PATH=custom/path
Use cases 1: Relevant code is spread across multiple repos and all of those are checked out next to each other (in
$(cwd)
) before building the image, e.g.Dockerfile is located in one of these repos, but as we need content from all 3 repos, we're setting build context to
$(cwd)
. This further means that we need to use the checkout name when specifying path forINCLUDE+
, e.g.repo_2/path/to/base
. So we have a hard-coded path that depends not only on the structure of the current repo (which is normal) but also on the name of the checkout (which doesn't have to match the repo name). This is not so bad from e.g. pipeline definition perspective (as it may also contain hard-coded checkout repo name), but it's not very convenient when engineers are configuring their local dev setup and need to make sure they follow expected naming convention when checking out relevant repos.Use case 2: Having the included path configurable via ARG would allow different Dockerfiles to be used as a base image. For example, when launching the setup locally, we'd like to import base Dockerfile and build the final image (in our case, testing image) in a single command (for simplicity). On the other hand, when building the image in some pipeline, we'd like to use another, dummy Dockerfile which just says
FROM base_image:latest
(where referenced image is pre-built), because pipeline is defined in code and it's not a problem to build image with 2 commands (one for the base one and one for the final//testing one). However, that approach would ensure we're exactly (re)using the pre-built base image to generate the final/testing one to execute tests - we're not rebuilding it from the scratch, which would (theoretically) make it not to be 100% based on the base image (which we'll use in production).The text was updated successfully, but these errors were encountered: