Installing the Datadog Agent to Collect Tests Data

Installing the Datadog Agent to Collect Tests Data

To report test results to Datadog, the Datadog Agent is required.

There are two ways to set up the Agent in a CI environment:

  • Install the Agent as a long running process on each worker node (recommended for on-premises installations).
  • Run an ephemeral instance of the Agent as a service container on each build (recommended for SaaS CI providers).

Installing the Agent on each CI worker node

If you are running tests on an on-premises CI provider, install the Datadog Agent on each worker node by following the Agent installation instructions.

If the CI provider is using a container-based executor, set the DD_AGENT_HOST environment variable on all builds (which defaults to localhost) to an endpoint that is accessible from within build containers, as localhost inside the build references the container itself and not the underlying worker node where the Datadog Agent is running.

If you are using a Kubernetes executor, Datadog recommends using the Admission Controller, which automatically sets the DD_AGENT_HOST environment variable in the build pods to communicate with the local Datadog Agent.

Installing the Datadog Agent as a service container on each build

If you are using a SaaS CI provider with no access to the underlying worker nodes, run the Datadog Agent in a container as a build service. This method is also available for an on-premises CI provider that uses a container-based executor if installing the Datadog Agent on each worker node is not an option.

To run the Datadog Agent as a container acting as a simple results forwarder, use the Docker image gcr.io/datadoghq/agent:latest and the following environment variables:

DD_API_KEY (Required)
The Datadog API key used to upload the test results.
Default: (none)
DD_INSIDE_CI (Required)
Disables the monitoring of the Datadog Agent container, as the underlying host is not accessible.
Default: false
Required value: true
DD_HOSTNAME (Required)
Disables the reporting of hostnames associated with tests, as the underlying host cannot be monitored.
Default: (autodetected)
Required value: none

Additionally, configure the Datadog site to use the selected one ():

DD_SITE (Required)
The Datadog site to upload results to.
Default: datadoghq.com
Selected site:

CI provider configuration examples

The following sections provide CI provider-specific instructions to run and configure the Agent to report test information.

    To run the Datadog Agent in Azure Pipelines, define a new container in the resources section and link it with the job declaring it as a service container:

    azure-pipeline.yml

    variables:
  ddApiKey: $(DD_API_KEY)

resources:
  containers:
    - container: dd_agent
      image: gcr.io/datadoghq/agent:latest
      ports:
        - 8126:8126
      env:
        DD_API_KEY: $(ddApiKey)
        DD_INSIDE_CI: "true"
        DD_HOSTNAME: "none"

jobs:
  - job: test
    services:
      dd_agent: dd_agent
    steps:
      - script: make test

    azure-pipeline.yml

    variables:
  ddApiKey: $(DD_API_KEY)

resources:
  containers:
    - container: dd_agent
      image: gcr.io/datadoghq/agent:latest
      ports:
        - 8126:8126
      env:
        DD_API_KEY: $(ddApiKey)
        DD_INSIDE_CI: "true"
        DD_HOSTNAME: "none"
        DD_SITE: "datadoghq.eu"

jobs:
  - job: test
    services:
      dd_agent: dd_agent
    steps:
      - script: make test

    Add your Datadog API key to your project environment variables with the key DD_API_KEY.

    To run the Agent in GitLab, define the Agent container under services:

    .gitlab-ci.yml

    variables:
  DD_API_KEY: $DD_API_KEY
  DD_INSIDE_CI: "true"
  DD_HOSTNAME: "none"
  DD_AGENT_HOST: "datadog-agent"

test:
  services:
    - name: gcr.io/datadoghq/agent:latest
  script:
    - make test

    .gitlab-ci.yml

    variables:
  DD_API_KEY: $DD_API_KEY
  DD_INSIDE_CI: "true"
  DD_HOSTNAME: "none"
  DD_AGENT_HOST: "datadog-agent"
  DD_SITE: "datadoghq.eu"

test:
  services:
    - name: gcr.io/datadoghq/agent:latest
  script:
    - make test

    Add your Datadog API key to your project environment variables with the key DD_API_KEY.

    To run the Agent in GitHub Actions, define the Agent container under services:

    jobs:
  test:
    services:
      datadog-agent:
        image: gcr.io/datadoghq/agent:latest
        ports:
          - 8126:8126
        env:
          DD_API_KEY: ${{ secrets.DD_API_KEY }}
          DD_INSIDE_CI: "true"
          DD_HOSTNAME: "none"
    steps:
      - run: make test

    jobs:
  test:
    services:
      datadog-agent:
        image: gcr.io/datadoghq/agent:latest
        ports:
          - 8126:8126
        env:
          DD_API_KEY: ${{ secrets.DD_API_KEY }}
          DD_INSIDE_CI: "true"
          DD_HOSTNAME: "none"
          DD_SITE: "datadoghq.eu"
    steps:
      - run: make test

    Add your Datadog API key to your project secrets with the key DD_API_KEY.

    To run the Agent in CircleCI, launch the Agent container before running tests by using the datadog/agent CircleCI orb, and stop it after to ensure results are sent to Datadog.

    For example:

    .circleci/config.yml

    version: 2.1

orbs:
  datadog-agent: datadog/agent@0

jobs:
  test:
    docker:
      - image: circleci/<language>:<version_tag>
    steps:
      - checkout
      - datadog-agent/setup
      - run: make test
      - datadog-agent/stop

workflows:
  test:
    jobs:
      - test

    .circleci/config.yml

    version: 2.1

orbs:
  datadog-agent: datadog/agent@0

jobs:
  test:
    docker:
      - image: circleci/<language>:<version_tag>
    environment:
      DD_SITE: "datadoghq.eu"
    steps:
      - checkout
      - datadog-agent/setup
      - run: make test
      - datadog-agent/stop

workflows:
  test:
    jobs:
      - test

    Add your Datadog API key to your project environment variables with the key DD_API_KEY.

    Using Docker Compose

    Regardless of which CI provider you use, if tests are run using Docker Compose, the Datadog Agent can be run as one service:

    docker-compose.yml

    version: '3'
services:
  datadog-agent:
    image: "gcr.io/datadoghq/agent:latest"
    environment:
      - DD_API_KEY
      - DD_INSIDE_CI=true
      - DD_HOSTNAME=none
    ports:
      - 8126/tcp

  tests:
    build: .
    environment:
      - DD_AGENT_HOST=datadog-agent

    docker-compose.yml

    version: '3'
services:
  datadog-agent:
    image: "gcr.io/datadoghq/agent:latest"
    environment:
      - DD_API_KEY
      - DD_INSIDE_CI=true
      - DD_HOSTNAME=none
      - DD_SITE=datadoghq.eu
    ports:
      - 8126/tcp

  tests:
    build: .
    environment:
      - DD_AGENT_HOST=datadog-agent

    Alternatively, share the same network namespace between the Agent container and the tests container:

    docker-compose.yml

    version: '3'
services:
  datadog-agent:
    image: "gcr.io/datadoghq/agent:latest"
    environment:
      - DD_API_KEY
      - DD_INSIDE_CI=true
      - DD_HOSTNAME=none

  tests:
    build: .
    network_mode: "service:datadog-agent"

    docker-compose.yml

    version: '3'
services:
  datadog-agent:
    image: "gcr.io/datadoghq/agent:latest"
    environment:
      - DD_API_KEY
      - DD_INSIDE_CI=true
      - DD_HOSTNAME=none
      - DD_SITE=datadoghq.eu

  tests:
    build: .
    network_mode: "service:datadog-agent"

    In this case, DD_AGENT_HOST is not required because it is localhost by default.

    Then, run your tests by providing your Datadog API key in the DD_API_KEY environment variable:

    DD_API_KEY=<YOUR_DD_API_KEY> docker-compose up \
  --build --abort-on-container-exit \
  tests

    Note: In this case, add all the required CI provider environment variables so build information can be attached to each test result, as described in Tests in containers.

    Further reading

    Additional helpful documentation, links, and articles:

    Forwarding Environment Variables for Tests in ContainersDOCUMENTATION more more Instrumenting tests in your languageNEXT STEP more more

    The selected Datadog site () is not supported at this time.