Currently, if there's an existing ambitious_azsdk_test_proxy container, the test_proxy fixture will just start that container. This means that the version of the test proxy tool could be outdated if the container was created with an old image tag.
A new container will be created with the latest version if the existing container is deleted before the fixture is called, but this requires manual intervention. It would be ideal to either check the existing image tag of the container, or fetch the correct image each time the fixture is invoked. The latter solution could be minimally time-consuming if Docker is smart about recognizing that the container already exists with the same image tag.
Currently, if there's an existing
ambitious_azsdk_test_proxycontainer, thetest_proxyfixture will just start that container. This means that the version of the test proxy tool could be outdated if the container was created with an old image tag.A new container will be created with the latest version if the existing container is deleted before the fixture is called, but this requires manual intervention. It would be ideal to either check the existing image tag of the container, or fetch the correct image each time the fixture is invoked. The latter solution could be minimally time-consuming if Docker is smart about recognizing that the container already exists with the same image tag.