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
If flag InitialPush is set, recordings will be automatically pushed to the assets repo and the Tag property updated.
23
23
24
24
.PARAMETERTestProxyExe
25
-
The executable used during the "InitialPush" action. Defaults to the dotnet tool test-proxy, but also supports "docker" or "podman".
25
+
The executable used during the "InitialPush" action. Defaults to the dotnet tool test-proxy, but also supports custom executables as well.
26
26
27
-
If the user provides their own value that doesn't match options "test-proxy", "docker", or "podman", the script will use this input as the test-proxy exe
27
+
If the user provides their own value that doesn't match options "test-proxy" the script will use this input as the test-proxy exe
28
28
when invoking commands. EG "$TestProxyExe push -a sdk/keyvault/azure-keyvault-keys/assets.json."
The test-proxy is also available from the [azure-sdk-for-net public feed](https://dev.azure.com/azure-sdk/public/_artifacts/feed/azure-sdk-for-net)
103
96
104
-
_Note: if you're not authorized to access these feeds, make sure you have [Azure Artifacts Credential Provider](https://github.com/microsoft/artifacts-credprovider) installed. You can also [download executable](#via-standalone-executable) or use a prebuilt [docker image](#via-docker-image)._
97
+
_Note: if you're not authorized to access these feeds, make sure you have [Azure Artifacts Credential Provider](https://github.com/microsoft/artifacts-credprovider) installed. You can also [download executable](#via-standalone-executable)._
105
98
106
99
To uninstall an existing test-proxy
107
100
@@ -121,40 +114,6 @@ If you've already installed the tool, you can always check the installed version
121
114
test-proxy --version
122
115
```
123
116
124
-
### Via Docker Image
125
-
126
-
The Azure SDK Team maintains a public Azure Container Registry.
127
-
128
-
```powershell
129
-
docker run -v <your-volume-name-or-location>:/srv/testproxy/ -p 5001:5001 -p 5000:5000 azsdkengsys.azurecr.io/engsys/test-proxy:latest
130
-
```
131
-
132
-
For example, to save test recordings to disk in your repo's `/sdk/<service>/tests/recordings` directory, provide the path to the root of the repo:
133
-
134
-
```powershell
135
-
docker run -v C:\\repo\\azure-sdk-for-<language>:/srv/testproxy/ -p 5001:5001 -p 5000:5000 azsdkengsys.azurecr.io/engsys/test-proxy:latest
136
-
```
137
-
138
-
Note the **port and volume mapping** as arguments! Any files that exist in this volume locally will only be appended to/updated in place. It is a non-destructive initialize.
139
-
140
-
Within the container, recording outputs are written within the directory `/srv/testproxy/`.
141
-
142
-
NOTE: if you are authenticated to github via SSH keys instead of a credential manager with https, you must mount your ssh credentials into docker. The following command shows an example mounting the default ssh key ~/.ssh/id_rsa on linux:
The azure-sdk team regularly update the image associated with the `latest` tag. Combined with the fact that docker will aggressively cache if possible, it is very possible that developers' local machines may be running outdated versions of the test-proxy.
151
-
152
-
To ensure that your local copy is up to date, run:
Standalone executable versions of the test-proxy are published to [github releases on this repository.](https://github.com/Azure/azure-sdk-tools/releases?q=Azure.Sdk.Tools.TestProxy&expanded=true)
@@ -286,7 +245,6 @@ The test-proxy is integrated with the following environment variables.
286
245
|`Logging__LogLevel__Default`| Defaults to `Information`. Possible valid values are <br/><br/>`Debug`, `Information`, `Warning`, `Error`, `Critical`.<br><br>Do not set for .NET test runs as it would cause the tests *themselves* to start emitting logs.|
287
246
|`Logging__LogLevel__Azure.Sdk.Tools.TestProxy`| Set to `Debug` to see request level logs emitted by the Test Proxy.|
288
247
289
-
Both of the above variables can be set in the `docker` runtime by providing additional arguments EG: `docker run -e Logging__LogLevel__Default=Warning azsdkengsys.azurecr.io/engsys/test-proxy:latest`. For multiple environment variables, just use multiple `-e` provisions.
290
248
291
249
## How do I use the test-proxy to get a recording?
292
250
@@ -312,7 +270,6 @@ A couple notes before running the test-proxy:
312
270
313
271
- Reference [command line arguments](#command-line-arguments) and understand the options.
314
272
- The test-proxy runs in a "context" which is just a directory on your disk. When initializing a recording, all paths should be relative to this context directory.
315
-
- If running the proxy as a docker image, ensure you **map**`etc/testproxy/` to a target context directory on your drive. In the example `docker run` invocations above, look for the `-v` argument.
316
273
317
274
### Where will my recordings end up?
318
275
@@ -789,36 +746,6 @@ Within this repository there is a single certificate.
789
746
790
747
-`eng/common/testproxy/dotnet-devcert.pfx`: generated on a `Ubuntu` distribution using `openssl`.
791
748
792
-
Unfortunately, the `dotnet dev-certs` generated certificates are _not_ acceptable to a standard ubuntu distro. The issue is that the `KeyUsage` field in the `.crt`[MUST contain](https://github.com/dotnet/aspnetcore/issues/7246#issuecomment-541165030) the `keyCertSign` flag. Certificates generated by `dotnet dev-certs` do NOT have this flag. This means that if you're on Windows AND running the Ubuntu docker image, you will need to trust the `dotnet-devcert.pfx` locally prior to `docker run`.
793
-
794
-
For further details on importing and using the provided dev-certificates, please investigate the [additional docker readme.](../docker/README.md)
795
-
796
-
### On Mac and Windows, .NET can be used to generate a local certificate
797
-
798
-
There are two options here, generate your own SSL Cert, or import an existing one.
799
-
800
-
#### Option 1
801
-
802
-
Invoke the command:
803
-
804
-
```powershell
805
-
dotnet dev-certs https --trust
806
-
```
807
-
808
-
This will be automatically retrieved if you run the nuget installed version of the tool. You may optionally use `openssl`[like so](https://raw.githubusercontent.com/BorisWilhelms/create-dotnet-devcert/f3b5da6f9107834eb31ea5ba7c0583e14cda6b31/create-dotnet-devcert.sh) to generate a certificate. Note that this shell script creates a dev cert that is compatible with ubuntu.
809
-
810
-
#### Option 2
811
-
812
-
Import the appropriate already existing certificate within the `eng/common/testproxy/` folder.
813
-
814
-
### Docker Image + SSL
815
-
816
-
To connect to the docker on SSL, both the docker image and your local machine must trust the same SSL cert. The docker image already has `dotnet-devcert.pfx` imported and trusted, so all that is necessary is to trust that same cert prior to `docker run`.
817
-
818
-
In the future, passing in a custom cert via a bound volume that contains your certificate will be a possibility as well.
819
-
820
-
For additional reading on this process for trusting SSL certs locally, feel free to read up [here.](https://devblogs.microsoft.com/aspnet/configuring-https-in-asp-net-core-across-different-platforms/) The afore-mentioned [docker specific readme](../docker/README.md) also has details that are relevant.
0 commit comments