TestProject Forum

Managing docker agents via API

Currently we use Azure Dev Ops for our build and deployment process. I am attempting to add the docker container to the mix. This is what I’m thinking the current process would be:

  1. Start up a docker test-agent (docker agent is auto-registered with TestProject, I’ve noticed)
  2. Point to the newly created agent (/v2/projects/{projectId}/jobs/{jobId}/agent/{agentId})
  3. Run the job on the new agent (/v2/projects/{projectId}/jobs/{jobId}/run)
  4. Wait for job to complete (how would we know?!?)
  5. Publish the test results to Azure
  6. Remove/destroy/cleanup the local docker test-agent
  7. Remove the new destroyed docker agent from TestProject (don’t see this API option)

My concerns here are:

  • We don’t know when the job is complete and would need to either poll (/v2/projects/{projectId}/jobs/{jobId}/executions/{executionId}/state) to find the state of the job, but I’m hoping that we could somehow monitor and wait for the execution results from the container as usually happens in Azure Dev Ops when running tests.
  • As we start and register/destroy docker agents, there will become a large number of agents in the “Agents” section of TestProject, won’t there? Unless we can remotely destroy/delete/remove them, the CI/CD will get a little cumbersome.


You should be starting an ephemeral instance

An ephemeral instance uses a pre-generated configuration token that contains information about the task that needs to be executed.
This configuration is passed to the container via the CONFIG environment variable or obtained automatically by the container on startup:

  1. Automatic process is triggered by setting the following environment variables:
  2. TP_API_KEY - The API key can be created in the TestProject Web Application (as described here).
  3. TP_JOB_ID - The ID of the job that the agent should execute. More information about this can be found here.
  4. TP_JOB_PARAMS - OPTIONAL variable that can be used to override the default job parameters.
  5. TP_AGENT_ALIAS - OPTIONAL variable that can be used for registering the agent with a custom alias.By setting the TP_API_KEY & TP_JOB_ID environment variables, the Agent will automatically request the job configuration and start the execution.
  6. Using TestProject’s RESTful API
    The response of this API contains a json with two fields:
{ "config": "string", "agentGuid": "string" }

The value of the config field should be passed to the container using the CONFIG environment variable.

The following command is an example for running an ephemeral instance:

$ docker run --rm \

Note the --rm argument to the docker run command.
Since the purpose of this instance is to perform a specific task (job) and terminate,
there’s no reason to keep the container after the execution, so in this example we use the --rm argument to automatically delete the container after the Agent exists.

read more here Docker Hub

Ah, OK. Thanks, @Mark_K

So I ran this using your setup (updating the API key and job ID to valid values for my project). Some more comments/questions:

I see the lines in the console that it’s registering and unregistering. Perfect! Exactly what I was looking for.

  • When doing the ephemeral, how do I tell the docker container where my browsers are? I ran the docker compose and it has environment variables CHROME and FIREFOX but docker compose seems to handle the networking correctly for those for me.
  • If I wanted to point to a remote webdriver hub (e.g. crossbrowsertesting), how do I pass that information to the docker test agent?
  • Is there any way to force it to unregister the agent via the docker compose (like it does with the -rm in the ephemeral method) when doing a docker compose down?


Played around a little more (following some of the steps in this thread) and was able to use the ephemeral method along with the docker compose.

Added the TP_JOB_ID as an environment variable when doing a docker compose up allowed for the ephemeral at least.

Still looking for passing the remote webdriver configuration somehow.

So I’m answering all of my own questions here, but for anyone else interested…

Got it working to connect to my remote webdriver hub, by doing this is my docker-compose file (this is for CrossBrowserTesting, but would be similar for sauce or browserstack I’d imagine

CHROME: "<CBTUser>:<CBTAuthKey>@hub.crossbrowsertesting.com:80"

And in my configs for the job, just put in all of your configuration settings (or modify “runtime”)

You folk at TestProject have just made these things way too simple :smiley: