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
When copying files into a container, you can specify the user ID (UID) and group ID (GID) to set the correct ownership of the copied files. This is particularly useful when the container runs as a non-root user or when specific file permissions are required for security or application functionality.
64
+
65
+
```csharp title="Copying a file with specific UID and GID"
The `Unix` class provides common permission configurations like `FileMode755` (read, write, execute for owner; read, execute for group and others). For individual permission combinations, you can use the `UnixFileModes` enumeration to create custom configurations.
80
+
81
+
### Copying files to a running container
82
+
83
+
The same UID, GID, and file mode arguments are also available when copying files to already running containers using the `IContainer.CopyAsync(...)` APIs.
84
+
61
85
## Reading files from the container
62
86
63
87
The `IContainer` interface offers a `ReadFileAsync(string, CancellationToken)` method to read files from the container. The implementation returns the read bytes. Either process the read bytes in-memory or persist them to the disk.
@@ -76,7 +100,8 @@ Starting a container or creating a resource (such as a network or a volume) can
76
100
77
101
```csharp title="Canceling container start after one minute"
@@ -86,7 +111,8 @@ Testcontainers for .NET provides two approaches for retrieving log messages from
86
111
The `GetLogsAsync` method is available through the `IContainer` interface. It allows you to fetch logs from a container for a specific time range or from the beginning until the present. This approach is useful for retrieving logs after a test has run, especially when troubleshooting issues or failures.
87
112
88
113
```csharp title="Getting all log messages"
89
-
var (stdout, stderr) =await_container.GetLogsAsync();
114
+
var (stdout, stderr) =await_container.GetLogsAsync()
115
+
.ConfigureAwait(false);
90
116
```
91
117
92
118
The `WithOutputConsumer` method is part of the `ContainerBuilder` class and is used to continuously forward container log messages to a specified output consumer. This approach provides real-time access to logs as the container runs.
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