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
To build a Docker image with Testcontainers, it's important to understand the build context. Testcontainers needs three things:
20
+
21
+
1.**Docker build context**: The directory containing files Docker can use during the build
22
+
2.**Dockerfile name**: The name of the Dockerfile to use
23
+
3.**Dockerfile directory**: Where the Dockerfile is located
24
+
19
25
!!!tip
20
26
21
-
The Dockerfile must be part of the build context, otherwise the build fails.
27
+
The build context is optional. If you don't specify one, it defaults to the Dockerfile directory.
28
+
29
+
Testcontainers creates a tarball with all files and subdirectorys in the build context, incl. the Dockerfile. This tarball is sent to the Docker daemon to build the image. The build context acts as the root for all file operations in the Dockerfile, so all paths (like `COPY` commands) must be relative to it.
22
30
23
-
It is essential to take into account and comprehend the build context to enable Testcontainers to build the Docker image. Testcontainers generates a tarball that contains all the files and subdirectories within the build context. The tarball is passed to the Docker daemon to build the image. The tarball serves as the new root of the Dockerfile's content. Therefore, all paths must be relative to the new root. If your app or service follows to the following project structure, the build context is`/Users/testcontainers/WeatherForecast/`.
31
+
For example, if your project looks like this, the build context would be:`/Users/testcontainers/WeatherForecast/`.
You can use `WithContextDirectory(string)` to set a build context separate from your Dockerfile. This is useful when the Dockerfile is in one directory but the files you want to include are in another.
A multi-stage Docker image build generates intermediate layers that serve as caches. Testcontainers' Resource Reaper is unable to automatically delete these layers after the test execution. The necessary label is not forwarded by the Docker image build. Testcontainers is unable to track the intermediate layers during the test. To delete the intermediate layers after the test execution, pass the Resource Reaper session to each stage.
@@ -92,8 +111,9 @@ _ = new ImageFromDockerfileBuilder()
92
111
|`WithCleanUp`| Will remove the image automatically after all tests have been run. |
93
112
|`WithLabel`| Applies metadata to the image e.g. `-l`, `--label "testcontainers=awesome"`. |
94
113
|`WithName`| Sets the image name e.g. `-t`, `--tag "testcontainers:0.1.0"`. |
114
+
|`WithContextDirectory`| Sets the Docker build context directory. |
95
115
|`WithDockerfile`| Sets the name of the `Dockerfile`. |
96
-
|`WithDockerfileDirectory`| Sets the build context (directory path that contains the `Dockerfile`).|
116
+
|`WithDockerfileDirectory`| Sets the directory path that contains the `Dockerfile`. |
97
117
|`WithImageBuildPolicy`| Specifies an image build policy to determine when an image is built. |
98
118
|`WithDeleteIfExists`| Will remove the image if it already exists. |
0 commit comments