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
buildkit: supports additionalBuildContext in builds via --build-context
As builds got more complicated, the ability to only access files from one location became quite limiting. With `multi-stage` builds where you can `copy` files from other parts of the Containerfile by adding the `--from` flag and pointing it to the name of another Containerfile stage or a remote image.
The new named build context feature is an extension of this pattern. You can now define additional build contexts when running the build command, give them a name, and then access them inside a Dockerfile the same way you previously did with build stages.
Additional build contexts can be defined with a new `--build-context [name]=[value]` flag. The key component defines the name for your build context and the value can be:
```console
Local directory – e.g. --build-context project2=../path/to/project2/src
HTTP URL to a tarball – e.g. --build-context src=https://example.org/releases/src.tar
Container image – Define with a docker-image:// prefix, e.g. --build-context alpine=docker-image://alpine:3.15, ( also supports docker://, container-image:// )
```
On the Containerfile side, you can reference the build context on all commands that accept the “from” parameter. Here’s how that might look:
```Dockerfile
FROM [name]
COPY --from=[name] ...
RUN --mount=from=[name] …
```
The value of [name] is matched with the following priority order:
* Named build context defined with `--build-context [name]=..`
* Stage defined with `AS [name]` inside Dockerfile
* Remote image `[name]` in a container registry
Added Features
* Pinning images for `FROM` and `COPY`
* Specifying multiple buildcontexts from different projects
and using them with `--from` in `ADD` and `COPY` directive
* Override a Remote Dependency with a Local One.
* Using additional context from external `Tar`
Signed-off-by: Aditya R <[email protected]>
Please refer to the [BUILD TIME VARIABLES](#build-time-variables) section for the
69
69
list of variables that can be overridden within the Containerfile at run time.
70
70
71
+
**--build-context***name=value*
72
+
73
+
Specify an additional build context using its short name and its location. Additional
74
+
build contexts can be referenced in the same manner as we access different stages in `COPY`
75
+
instruction.
76
+
77
+
Valid values could be:
78
+
* Local directory – e.g. --build-context project2=../path/to/project2/src
79
+
* HTTP URL to a tarball – e.g. --build-context src=https://example.org/releases/src.tar
80
+
* Container image – specified with a container-image:// prefix, e.g. --build-context alpine=container-image://alpine:3.15, ( also accepts docker://, docker-image://)
81
+
82
+
On the Containerfile side, you can reference the build context on all commands that accept the “from” parameter.
83
+
Here’s how that might look:
84
+
85
+
```Dockerfile
86
+
FROM [name]
87
+
COPY --from=[name] ...
88
+
RUN --mount=from=[name] …
89
+
```
90
+
91
+
The value of `[name]` is matched with the following priority order:
92
+
93
+
* Named build context defined with --build-context [name]=..
94
+
* Stage defined with AS [name] inside Containerfile
95
+
* Image [name], either local or in a remote registry
96
+
71
97
**--cache-from**
72
98
73
99
Images to utilise as potential cache sources. Buildah does not currently support --cache-from so this is a NOOP.
ifreplaceBuildContext, ok:=additionalBuildContext[child.Next.Value]; ok {
679
+
ifreplaceBuildContext.IsImage {
680
+
child.Next.Value=replaceBuildContext.Value
681
+
} else {
682
+
logger.Warnf("additionalContext for nickname %q was found but its not an image hence it will be not used with FROM %q", child.Next.Value, child.Next.Value)
0 commit comments