Readme for standalone executable + codespaces token conflicts

tools/test-proxy/Azure.Sdk.Tools.TestProxy/README.md

@@ -5,6 +5,8 @@
     - [Via Local Compile or .NET](#via-local-compile-or-net)
     - [Via Docker Image](#via-docker-image)
       - [A note about docker caching](#a-note-about-docker-caching)
+    - [Via Standalone Executable](#via-standalone-executable)
+      - [Which should I install?](#which-should-i-install)
   - [Command line arguments](#command-line-arguments)
     - [Storage Location](#storage-location)
     - [Port Assignation](#port-assignation)
@@ -78,6 +80,7 @@ dotnet tool update azure.sdk.tools.testproxy --global --add-source https://pkgs.
 ```
 
 To uninstall an existing test-proxy
+
 ```powershell
 dotnet tool uninstall --global azure.sdk.tools.testproxy
 ```
@@ -130,6 +133,20 @@ To ensure that your local copy is up to date, run:
 docker pull azsdkengsys.azurecr.io/engsys/test-proxy:latest
 ```
 
+### Via Standalone Executable
+
+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)
+
+These executables are produced for multiple platforms and are available attached as `assets`:
+
+![image](https://user-images.githubusercontent.com/45376673/224413965-30a1e34f-5517-447c-9709-cfa81b117d5c.png)
+
+#### Which should I install?
+
+The version suffix for each release is based on the date. In most cases, the latest version should be totally stable.
+
+For safety, the "official target" version that the azure-sdk team uses is present within [`eng/common/testproxy/target_version.txt`](../../../eng/common/testproxy/target_version.txt). New "official" versions are tested by all consumers prior to updating the target version within this file.
+
 ## Command line arguments
 
 This is the help information for test-proxy. It uses the nuget package [`CommandLineParser`](https://www.nuget.org/packages/CommandLineParser) to parse arguments.
@@ -203,9 +220,9 @@ The test-proxy is integrated with the following environment variables.
 | Variable | Usage |
 |---|---|
 | `TEST_PROXY_FOLDER` | if command-line argument `storage-location` is not provided when invoking the proxy, this environment variable is also checked for a valid directory to use as test-proxy context. |
-| `Logging__LogLevel__Microsoft` | Defaults to `Information`. Possible valid values are `Information`, `Warning`, `Error`, `Critical`.  |
+| `Logging__LogLevel__Default` | Defaults to `Information`. Possible valid values are `Information`, `Warning`, `Error`, `Critical`.  |
 
-Both of the above variables can be set in the `docker` runtime by providing additional arguments EG: `docker run -e Logging__LogLevel__Microsoft=Warning azsdkengsys.azurecr.io/engsys/test-proxy:latest`. For multiple environment variables, just use multiple `-e` provisions.
+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.
 
 ## How do I use the test-proxy to get a recording?
 

tools/test-proxy/documentation/asset-sync/README.md

@@ -246,6 +246,22 @@ So to make a push work for the above scenario, all one must do is only include t
 docker run --rm -v "C:/repo/sdk-for-python:/srv/testproxy"  -e "GIT_TOKEN=myveryrealtoken" -e "GIT_COMMIT_OWNER=scbedd" -e  "[email protected]" azsdkengsys.azurecr.io/engsys/test-proxy:latest test-proxy push -a sdk/tables/assets.json
 ```
 
+#### An additional note about using `test-proxy push` in codespaces
+
+The `test-proxy` can (and is) used to run tests in github codespaces. However, there is a wrinkle when **pushing** from a default codespaces configuration to the assets repository.
+
+A dev (@timovv) on the azure-sdk-for-js team succinctly states the problem:
+
+> GitHub grants minimal permissions to a Codespace when it is created through creating a personal access token (PAT). By default, this PAT only grants write access to the repo that the Codespace was created from. This causes permissions issues when pushing assets to the Azure/azure-sdk-assets repo since the PAT does not grant write permission to that repo. Fortunately, we can request additional permissions through the devcontainer.json, which will give the Codespace write access to the Azure/azure-sdk-assets repo.
+
+[CodeSpaces reference about this topic](https://docs.github.com/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces).
+
+The `azure-sdk` team has chosen to address this difficulty by [applying the following customization](https://github.com/Azure/azure-sdk-for-js/pull/24963/files) to `devcontainer.json` for each language repo. This means that codespaces created off of the upstream repo will automagically have the correct permissions to push to `azure-sdk-assets`.
+
+> **Note** Codespaces created on **forks** do not magically gain write permissions to `azure-sdk-assets`.
+
+To push from a codespace on a fork, devs will need to set `GIT_TOKEN` themselves to a PAT that has write access to `azure-sdk-assets`. Effectively the same route as if they wanted to use docker.
+
 ### I am getting weird errors out of my test-proxy operations
 
 If you think that the `test-proxy` has somehow gotten itself into a weird "in-between" state that it can't automatically dig itself out of, you have a couple options.