Cette page n'est pas encore disponible en français, sa traduction est en cours.
Si vous avez des questions ou des retours sur notre projet de traduction actuel, n'hésitez pas à nous contacter.

Overview

Datadog’s Source Code Integration allows you to connect your Git repositories to Datadog to enable various source code-related features across the Datadog platform. It allows debugging stack traces, slow profiles, and other issues by accessing the relevant lines of your source code.

Inline code snippet of a Java RuntimeException with a button to view the code in GitHub

Connect your Git repositories to Datadog

To use most source code-related features, you must connect your Git repositories to Datadog. By default, when synchronizing your repositories, Datadog doesn’t store the actual content of files in your repository, only the Git commit and tree objects.

Source code management providers

Datadog supports the following features for the following source code management (SCM) providers. See Usage for more details about each feature:

FeatureGitHubGitLabAzure DevOpsBitbucket
Connect SaaS InstanceYes
(GitHub.com)
Yes
(GitLab.com)
Yes
(Azure DevOps Services)
No
(Bitbucket.org)
Connect On-Prem InstanceYes
(GitHub Enterprise Server)
Yes
(GitLab Self-Managed or Dedicated)
No
(Azure DevOps Server)
No
(Bitbucket Data Center or Server)
Context LinksYesYesYesYes
Code SnippetsYesYesYesNo
PR CommentsYesYesYesNo
Repositories from GitHub instances are supported for both GitHub.com (SaaS) and GitHub Enterprise Server (On-Prem). For GitHub Enterprise Server, your instance must be accessible from the internet. If needed, you can allowlist Datadog's webhooks IP addresses to allow Datadog to connect to your instance.

Install Datadog’s GitHub integration using the integration tile or while onboarding other Datadog products to connect to your GitHub repositories.

Repositories from GitLab instances are supported in closed Preview. Repositories from GitLab instances are supported for both GitLab.com (SaaS) and GitLab Self-Managed/Dedicated (On-Prem). For GitLab Self-Managed, your instance must be accessible from the internet. If needed, you can allowlist Datadog's webhooks IP addresses to allow Datadog to connect to your instance. Join the Preview.

Install Datadog’s GitLab Source Code integration using the integration tile or while onboarding other Datadog products to connect to your GitLab repositories.

Repositories from Azure DevOps are supported in closed Preview. Join the Preview.

Install Datadog’s Azure DevOps Source Code integration while onboarding to Datadog Code Security. This integration’s functionality is limited to Code Security.

Repositories on self-hosted instances or private URLs are not supported out-of-the-box. To enable this feature, contact Support.

If you are using any other SCM provider, you can still manually link telemetry with your source code. To do so, upload your repository metadata with the datadog-ci git-metadata upload command. datadog-ci v2.10.0 or later is required.

When you run datadog-ci git-metadata upload within a Git repository, Datadog receives the repository URL, the commit SHA of the current branch, and a list of tracked file paths.

Run this command for every commit that you need to be synchronized with Datadog.

Validation

To ensure the data is being collected, run datadog-ci git-metadata upload in your CI pipeline.

You can expect to see the following output:

Reporting commit 007f7f466e035b052415134600ea899693e7bb34 from repository git@my-git-server.com:my-org/my-repository.git.
180 tracked file paths will be reported.
Successfully uploaded tracked files in 1.358 seconds.
Syncing GitDB...
Successfully synced git DB in 3.579 seconds.
 Uploaded in 5.207 seconds.

Tag your APM Telemetry with Git information

Datadog Agent v7.35.0 or later is required.

If you have APM set up already, navigate to Integrations > Link Source Code and configure the source code integration for your backend services.

Your telemetry must be tagged with Git information that ties the running application version with a particular repository and commit.

For supported languages, Datadog recommends embedding Git information in the deployed artifacts, which is then extracted by the Datadog Tracing Libraries automatically.

For other languages and configurations, you can configure telemetry tagging yourself.

Embed Git information in your build artifacts

You can embed the repository URL and commit hash in your build artifact. The Datadog Tracing Libraries use this information to automatically add the right tags to your APM service telemetry.

Select one of the following languages that supports embedding git information:

The Go client library version 1.48.0 or later is required.

Containers

If you are using Docker containers, you have three options: using Docker, using the Datadog tracing library, or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Ajoutez les lignes suivantes dans le Dockerfile de votre application :

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Ajoutez les arguments suivants à votre commande build Docker :

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: Datadog Tracing Library

Depuis la version 1.18, Go intègre les informations sur le contrôle des versions dans des binaires. La bibliothèque de tracing Datadog se sert de ces informations pour taguer vos données de télémétrie avec le SHA du commit et l’URL du référentiel les plus récents.

Pour adopter cette approche, vérifiez que votre service respecte les exigences suivantes :

  • Version 1.18 ou ultérieure de Go
  • Service conçu en tant que module Go, dont le chemin correspond à l’URL du référentiel de votre code
Option 3: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Serverless

If you are using Serverless, you have three options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Outil CLI Datadog
Utilisez la version 2.4.1 ou une version ultérieure du client datadog-ci. Vous devez exécuter l’outil CLI dans le même répertoire que le référentiel de code.
Plug-in Serverless Datadog
Utilisez la version 5.18.0 ou une version ultérieure du plug-in.
CDK Construct Datadog
Utilisez la version 0.8.5 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v1.
Utilisez la version 1.4.0 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v2.
Option 2: Datadog Tracing Library

Depuis la version 1.18, Go intègre les informations sur le contrôle des versions dans des binaires. La bibliothèque de tracing Datadog se sert de ces informations pour taguer vos données de télémétrie avec le SHA du commit et l’URL du référentiel les plus récents.

Pour adopter cette approche, vérifiez que votre service respecte les exigences suivantes :

  • Version 1.18 ou ultérieure de Go
  • Service conçu en tant que module Go, dont le chemin correspond à l’URL du référentiel de votre code
Option 3: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Host

If you are using a host, you have two options.

Option 1: Datadog Tracing Library

Depuis la version 1.18, Go intègre les informations sur le contrôle des versions dans des binaires. La bibliothèque de tracing Datadog se sert de ces informations pour taguer vos données de télémétrie avec le SHA du commit et l’URL du référentiel les plus récents.

Pour adopter cette approche, vérifiez que votre service respecte les exigences suivantes :

  • Version 1.18 ou ultérieure de Go
  • Service conçu en tant que module Go, dont le chemin correspond à l’URL du référentiel de votre code
Option 2: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

The Python client library version 1.12.0 or later is required.

Containers

If you are using Docker containers, you have three options: using Docker, using the Datadog tracing library, or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Ajoutez les lignes suivantes dans le Dockerfile de votre application :

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Ajoutez les arguments suivants à votre commande build Docker :

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: Setuptools or Unified Python Project Settings File

Si le package de votre application est généré avec setuptools :

  1. Installez le package dd-trace.
  2. Ajoutez import ddtrace.sourcecode.setuptools_auto en tant que première importation dans le fichier setup.py.
  3. Définissez la variable d’environnement DD_MAIN_PACKAGE sur le nom du principal package Python.

Si vous utilisez un fichier unifié contenant les paramètres du projet Python pour votre application :

  1. Installez le plug-in hatch-datadog-build-metadata et configurez-le de façon à intégrer les métadonnées git. Si un projet contient déjà des URL, reconfigurez-les afin d’utiliser des URL dynamiques, puis déplacez-les vers une autre section de configuration. Pour en savoir plus, consultez le code source du plug-in.
  2. Définissez la variable d’environnement DD_MAIN_PACKAGE sur le nom du principal package Python.
Option 3: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Serverless

If you are using Serverless, you have three options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Outil CLI Datadog
Utilisez la version 2.4.1 ou une version ultérieure du client datadog-ci. Vous devez exécuter l’outil CLI dans le même répertoire que le référentiel de code.
Plug-in Serverless Datadog
Utilisez la version 5.18.0 ou une version ultérieure du plug-in.
CDK Construct Datadog
Utilisez la version 0.8.5 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v1.
Utilisez la version 1.4.0 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v2.
Option 2: Setuptools or Unified Python Project Settings File

Si le package de votre application est généré avec setuptools :

  1. Installez le package dd-trace.
  2. Ajoutez import ddtrace.sourcecode.setuptools_auto en tant que première importation dans le fichier setup.py.
  3. Définissez la variable d’environnement DD_MAIN_PACKAGE sur le nom du principal package Python.

Si vous utilisez un fichier unifié contenant les paramètres du projet Python pour votre application :

  1. Installez le plug-in hatch-datadog-build-metadata et configurez-le de façon à intégrer les métadonnées git. Si un projet contient déjà des URL, reconfigurez-les afin d’utiliser des URL dynamiques, puis déplacez-les vers une autre section de configuration. Pour en savoir plus, consultez le code source du plug-in.
  2. Définissez la variable d’environnement DD_MAIN_PACKAGE sur le nom du principal package Python.
Option 3: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Host

If you are using a host, you have two options.

Option 1: Setuptools or Unified Python Project Settings File

Si le package de votre application est généré avec setuptools :

  1. Installez le package dd-trace.
  2. Ajoutez import ddtrace.sourcecode.setuptools_auto en tant que première importation dans le fichier setup.py.
  3. Définissez la variable d’environnement DD_MAIN_PACKAGE sur le nom du principal package Python.

Si vous utilisez un fichier unifié contenant les paramètres du projet Python pour votre application :

  1. Installez le plug-in hatch-datadog-build-metadata et configurez-le de façon à intégrer les métadonnées git. Si un projet contient déjà des URL, reconfigurez-les afin d’utiliser des URL dynamiques, puis déplacez-les vers une autre section de configuration. Pour en savoir plus, consultez le code source du plug-in.
  2. Définissez la variable d’environnement DD_MAIN_PACKAGE sur le nom du principal package Python.
Option 2: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

The .NET client library version 2.24.1 or later is required.

As a first step, ensure that your .pdb files are deployed alongside your .NET assemblies (.dll or .exe) in the same folder. Then, follow the rest of the instructions based on your specific deployment model:

Containers

If you are using Docker containers, you have three options: using Docker, using Microsoft SourceLink, or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Ajoutez les lignes suivantes dans le Dockerfile de votre application :

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Ajoutez les arguments suivants à votre commande build Docker :

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    

Si vous utilisez Microsoft SourceLink, Dtadog peut extraire le SHA du commit git et l’URL du référentiel à partir de l’assemblage .NET.

  1. Ouvrez le fichier de votre projet (.csproj) dans un environnement de développement intégré (EDI), puis ajoutez une référence à l’un des packages NuGet suivants, selon l’endroit où votre référentiel git est hébergé :
    FournisseurMicrosoft SourceLink
    GitHubMicrosoft.SourceLink.GitHub
    BitbucketMicrosoft.SourceLink.Bitbucket.Git
    GitLabMicrosoft.SourceLink.GitLab
    Azure DevOpsMicrosoft.SourceLink.AzureRepos.Git
    Azure DevOps ServerMicrosoft.SourceLink.AzureDevOpsServer.Git
Option 3: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Serverless

If you are using Serverless, you have three options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Outil CLI Datadog
Utilisez la version 2.4.1 ou une version ultérieure du client datadog-ci. Vous devez exécuter l’outil CLI dans le même répertoire que le référentiel de code.
Plug-in Serverless Datadog
Utilisez la version 5.18.0 ou une version ultérieure du plug-in.
CDK Construct Datadog
Utilisez la version 0.8.5 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v1.
Utilisez la version 1.4.0 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v2.

Si vous utilisez Microsoft SourceLink, Dtadog peut extraire le SHA du commit git et l’URL du référentiel à partir de l’assemblage .NET.

  1. Ouvrez le fichier de votre projet (.csproj) dans un environnement de développement intégré (EDI), puis ajoutez une référence à l’un des packages NuGet suivants, selon l’endroit où votre référentiel git est hébergé :
    FournisseurMicrosoft SourceLink
    GitHubMicrosoft.SourceLink.GitHub
    BitbucketMicrosoft.SourceLink.Bitbucket.Git
    GitLabMicrosoft.SourceLink.GitLab
    Azure DevOpsMicrosoft.SourceLink.AzureRepos.Git
    Azure DevOps ServerMicrosoft.SourceLink.AzureDevOpsServer.Git
Option 3: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Host

If you are using a host, you have two options: using Microsoft SourceLink or configuring your application with DD_GIT_* environment variables.

Si vous utilisez Microsoft SourceLink, Dtadog peut extraire le SHA du commit git et l’URL du référentiel à partir de l’assemblage .NET.

  1. Ouvrez le fichier de votre projet (.csproj) dans un environnement de développement intégré (EDI), puis ajoutez une référence à l’un des packages NuGet suivants, selon l’endroit où votre référentiel git est hébergé :
    FournisseurMicrosoft SourceLink
    GitHubMicrosoft.SourceLink.GitHub
    BitbucketMicrosoft.SourceLink.Bitbucket.Git
    GitLabMicrosoft.SourceLink.GitLab
    Azure DevOpsMicrosoft.SourceLink.AzureRepos.Git
    Azure DevOps ServerMicrosoft.SourceLink.AzureDevOpsServer.Git
Option 2: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

The Node.js client library version 3.21.0 or later is required.

For transpiled Node.js applications (for example, TypeScript), make sure to generate and publish source maps with the deployed application, and to run Node.js with the --enable-source-maps flag. Otherwise, code links and snippets will not work.

Containers

If you are using Docker containers, you have two options: using Docker or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Ajoutez les lignes suivantes dans le Dockerfile de votre application :

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Ajoutez les arguments suivants à votre commande build Docker :

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Serverless

If you are using Serverless, you have two options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Outil CLI Datadog
Utilisez la version 2.4.1 ou une version ultérieure du client datadog-ci. Vous devez exécuter l’outil CLI dans le même répertoire que le référentiel de code.
Plug-in Serverless Datadog
Utilisez la version 5.18.0 ou une version ultérieure du plug-in.
CDK Construct Datadog
Utilisez la version 0.8.5 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v1.
Utilisez la version 1.4.0 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v2.
Option 2: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Host

If you are using a host, configure your application with DD_GIT_* environment variables.

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

The Ruby client library version 1.6.0 or later is required.

Containers

If you are using Docker containers, you have two options: using Docker or configuring your application with the DD_TAGS environment variable.

Option 1: Docker
  1. Ajoutez les lignes suivantes dans le Dockerfile de votre application :

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_TAGS="git.repository_url:${DD_GIT_REPOSITORY_URL},git.commit.sha:${DD_GIT_COMMIT_SHA}"
    
  2. Ajoutez les arguments suivants à votre commande build Docker :

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: DD_TAGS Environment Variable

Configurez votre application avec la variable d’environnement DD_TAGS :

export DD_TAGS="git.commit.sha:<commit_Sha>,git.repository_url:<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Serverless

If you are using Serverless, you have two options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Outil CLI Datadog
Utilisez la version 2.4.1 ou une version ultérieure du client datadog-ci. Vous devez exécuter l’outil CLI dans le même répertoire que le référentiel de code.
Plug-in Serverless Datadog
Utilisez la version 5.18.0 ou une version ultérieure du plug-in.
CDK Construct Datadog
Utilisez la version 0.8.5 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v1.
Utilisez la version 1.4.0 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v2.
Option 2: DD_TAGS Environment Variable

Configurez votre application avec la variable d’environnement DD_TAGS :

export DD_TAGS="git.commit.sha:<commit_Sha>,git.repository_url:<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Host

If you are using a host, configure your application with the DD_TAGS environment variable.

Configurez votre application avec la variable d’environnement DD_TAGS :

export DD_TAGS="git.commit.sha:<commit_Sha>,git.repository_url:<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

The Java client library version 1.12.0 or later is required.

Containers

If you are using Docker containers, you have two options: using Docker or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Ajoutez les lignes suivantes dans le Dockerfile de votre application :

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Ajoutez les arguments suivants à votre commande build Docker :

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Serverless

If you are using Serverless, you have two options depending on your serverless application’s setup.

Option 1: Datadog Tooling
Outil CLI Datadog
Utilisez la version 2.4.1 ou une version ultérieure du client datadog-ci. Vous devez exécuter l’outil CLI dans le même répertoire que le référentiel de code.
Plug-in Serverless Datadog
Utilisez la version 5.18.0 ou une version ultérieure du plug-in.
CDK Construct Datadog
Utilisez la version 0.8.5 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v1.
Utilisez la version 1.4.0 ou une version ultérieure de datadog-cdk-constructs pour AWS CDK v2.
Option 2: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Host

If you are using a host, configure your application with DD_GIT_* environment variables.

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

The PHP client library version 1.2.0 or later is required.

Containers

If you are using Docker containers, you have two options: using Docker or configuring your application with DD_GIT_* environment variables.

Option 1: Docker
  1. Ajoutez les lignes suivantes dans le Dockerfile de votre application :

    ARG DD_GIT_REPOSITORY_URL
    ARG DD_GIT_COMMIT_SHA
    ENV DD_GIT_REPOSITORY_URL=${DD_GIT_REPOSITORY_URL} 
    ENV DD_GIT_COMMIT_SHA=${DD_GIT_COMMIT_SHA}
    
  2. Ajoutez les arguments suivants à votre commande build Docker :

    docker build . \
     -t my-application \
     --build-arg DD_GIT_REPOSITORY_URL=<git-provider.example/me/my-repo> \
     --build-arg DD_GIT_COMMIT_SHA=$(git rev-parse HEAD)
    
Option 2: DD_GIT_* Environment Variables

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Host

If you are using a host, configure your application with DD_GIT_* environment variables.

Configurez votre application avec les variables d’environnement DD_GIT_* :

export DD_GIT_COMMIT_SHA="<commit_Sha>"
export DD_GIT_REPOSITORY_URL="<git-provider.example/me/my-repo>"

Remplacez <commit_Sha> par le SHA du commit servant à build votre application. Pour l’obtenir, exécutez git rev-parse HEAD lors du build. Le SHA doit être passé aux variables d’environnement du runtime.

Build inside a Docker container

If your build process is executed in CI within a Docker container, perform the following steps to ensure that the build can access Git information:

  1. Add the following text to your .dockerignore file. This ensures that the build process is able to access a subset of the .git folder, enabling it to determine the git commit hash and repository URL.

    !.git/HEAD
    !.git/config
    !.git/refs
    
  2. Add the following line of code to your Dockerfile. Ensure that it is placed before the actual build is ran.

    COPY .git ./.git
    

Configure telemetry tagging

For unsupported languages, use the git.commit.sha and git.repository_url tags to link data to a specific commit. Ensure that the git.repository_url tag does not contain protocols. For example, if your repository URL is https://github.com/example/repo, the value for the git.repository_url tag should be github.com/example/repo.

Usage

You can see links from stack frames to their source repository in Error Tracking.

  1. Navigate to APM > Error Tracking.
  2. Click on an issue. The Issue Details panel appears on the right.
  3. Under Latest Event, if you’re using the GitHub or GitLab integrations, click Connect to preview on stack frames. You can see inline code snippets directly in the stack trace. Otherwise, you can click the View button on the right of a frame or select View file, View Git blame, or View commit to be redirected to your source code management tool.
A view repository button with three options (view file, view blame, and view commit) available on the right side of an error stack trace in Error Tracking, along with inline code snippets in the stack trace

You can see a source code preview for profile frames in the Continuous Profiler.

  1. Navigate to APM > Profile Search.
  2. Hover your cursor over a method in the flame graph.
  3. If needed, press Opt or Alt to enable the preview.
  4. If you’re using the GitHub or GitLab integrations, click Connect to preview to see inline code snippets directly in the flame graph.
Source code preview in the Continuous Profiler

You can also see links from profile frames to their source repository. This is supported for profiles broken down by line, method, or file.

  1. Navigate to APM > Profile Search.
  2. Hover your cursor over a method in the flame graph. A kebab icon with the More actions label appears on the right.
  3. Click More actions > View in repo to open the trace in its source code repository.
Link to GitHub from the Continuous Profiler

You can see links from errors in your Lambda functions’ associated stack traces to their source repository in Serverless Monitoring.

  1. Navigate to Infrastructure > Serverless and click on the AWS tab.
  2. Click on a Lambda function and click the Open Trace button for an invocation with an associated stack trace.
  3. If you’re using the GitHub or GitLab integrations, click Connect to preview on stack frames. You can see inline code snippets directly in the stack trace. Otherwise, you can click the View button on the right of a frame or select View file, View Git blame, or View commit to be redirected to your source code management tool.

You can see links from failed test runs to their source repository in Test Optimization.

  1. Navigate to Software Delivery > Test Optimization > Test Runs and select a failed test run.
  2. If you’re using the GitHub or GitLab integrations, click Connect to preview on stack frames. You can see inline code snippets directly in the stack trace. Otherwise, you can click the View button on the right of a frame or select View file, View Git blame, or View commit to be redirected to your source code management tool.
Link to GitHub from the CI Visibility Explorer

For more information, see Enhancing Developer Workflows with Datadog.

You can see links from failed Static Analysis and Software Composition Analysis scans to their source repository in Code Security.

  1. Navigate to Software Delivery > Code Security and select a repository.
  2. In the Code Vulnerabilities or Code Quality view, click on a code vulnerability or violation. In the Details section, if you’re using the GitHub, GitLab, or Azure DevOps integrations, click Connect to preview. You can see inline code snippets highlighting the exact lines of code that triggered the vulnerability or violation. Otherwise, you can click the View button on the right of a frame or select View file, View Git blame, or View commit to be redirected to your source code management tool.
Link to GitHub from the Code Security Code Vulnerabilities view

For more information, see the Code Security documentation.

You can see links from errors in your security signals’ associated stack traces to their source repository in App and API Protection Monitoring.

  1. Navigate to Security > App and API Protection and select a security signal.
  2. Scroll down to the Traces section on the Related Signals tab and click on an associated stack trace.
  3. If you’re using the GitHub or GitLab integrations, click Connect to preview on stack frames. You can see inline code snippets directly in the stack trace. Otherwise, you can click the View button on the right of a frame or select View file, View Git blame, or View commit to be redirected to your source code management tool.
Link to GitHub from App and API Protection Monitoring

You can see full source code files in Dynamic Instrumentation when creating or editing an instrumentation (dynamic log, metric, span, or span tags).

Create new instrumentation

  1. Navigate to APM > Dynamic Instrumentation.
  2. Select Create New Instrumentation and choose a service to instrument.
  3. Search for and select a source code filename or method.

View or edit instrumentation

  1. Navigate to APM > Dynamic Instrumentation.
  2. Select an existing instrumentation from the list, then click View Events.
  3. Select the instrumentation card to view its location in the source code.
Source Code File in Dynamic Instrumentation

For more information, see the Dynamic Instrumentation documentation.

PR comments

PR comments are enabled by default when first onboarding to CI Visibility if the GitHub or GitLab integration is installed correctly. These integrations post a comment summarizing the failed jobs detected in your pull request.

PR Comment summarizing failed jobs detected by CI Visibility

To disable PR comments for CI Visibility, go to the CI Visibility Repository Settings.

PR comments are enabled by default when first onboarding to Code Security if the GitHub, GitLab, or Azure DevOps integration is installed correctly. These integrations post two types of comments on your pull requests:

  1. A single comment summarizing the new violations detected in your pull request.
PR Comment summarizing the new violations detected by Code Security
  1. Inline comments for each violation detected in your pull request placed directly on the lines of code that triggered the violation in the diff of the pull request.
Inline comment for a specific violation detected by Code Security

To disable PR comments for Code Security, go to the Code Security Repository Settings.

PR comments are enabled by default when first onboarding to Test Optimization if the GitHub or GitLab integration is installed correctly. The integration posts a comment summarizing the failed and flaky tests detected in your pull request.

PR Comment summarizing failed and flaky tests detected by Test Optimization

To disable PR comments for Test Optimization, go to the Test Optimization Advanced Features Settings.

Further Reading