Integración del código fuente de Datadog

Información general

La integración del código fuente en Datadog te permite conectar tus repositorios Git con Datadog para habilitar diferentes funciones relacionadas con el código fuente en toda la plataforma Datadog. Permite depurar trazas (traces) de stack tecnológico, perfiles lentos y otros problemas accediendo a las líneas relevantes de tu código fuente.

Fragmento de código en línea de una clase RuntimeException de Java, con un botón para visualizar el código en GitHub

Conectar tus repositorios Git con Datadog

Para utilizar la mayoría de las funciones relacionadas con el código fuente, debes conectar tus repositorios Git con Datadog. Por defecto, al sincronizar tus repositorios, Datadog no almacena el contenido real de los archivos de tu repositorio, sólo los objetos Git commit y tree.

Proveedores de gestión de código fuente

Datadog admite las siguientes funciones para los siguientes proveedores de gestión de código fuente (SCM). Para ver más detalles sobre cada función, consulta Uso:

FunciónGitHubGitLabAzure DevOpsBitbucket
Conectar instancia SaaS
(GitHub.com y GitHub Enterprise Cloud)

(GitLab.com)

(Azure DevOps Services)
No
(Bitbucket.org)
Conectar instancia On-Prem
(GitHub Enterprise Server)

(GitLab autogestionado o exclusivo)
No
(Azure DevOps Server)
No
(Centro de datos o servidor Bitbucket)
Enlaces de contexto
Fragmentos de códigoNo
Comentarios en solicitudes pullNo
Los repositorios de las instancias de GitHub son compatibles con GitHub.com, GitHub Enterprise Cloud (SaaS) y GitHub Enterprise Server (On-Prem). Para GitHub Enterprise Server, tu instancia debe ser accesible desde Internet. Si es necesario, puedes permitir direcciones IP de webhooks de Datadog para que Datadog pueda conectarse a tu instancia.

Instala la integración GitHub de Datadog utilizando el cuadro de la integración o mientras accedes a otros productos de Datadog para conectarte a tus repositorios de GitHub.

Los repositorios de las instancias de GitLab son compatibles con la vista previa cerrada. Los repositorios de las instancias de GitLab son compatibles tanto con GitLab.com (SaaS) como con GitLab Self-Managed/Dedicated (On-Prem). Para GitLab Self-Managed, tu instancia debe ser accesible desde Internet. Si es necesario, puedes permitir direcciones IP de webhooks de Datadog para que Datadog pueda conectarse a tu instancia. Únete a la vista previa.

Instala la integración del código fuente de GitHub de Datadog utilizando el cuadro de la integración o mientras accedes a otros productos de Datadog para conectarte a tus repositorios de GitHub.

Los repositorios de Azure DevOps son compatibles con la vista previa cerrada. Únete a la vista previa.

Instala la integración del código fuente de Azure DevOps de Datadog mientras accedes a Datadog Code Security. La funcionalidad de esta integración se limita a Code Security.

Los repositorios en instancias autoalojadas o URL privadas no son compatibles de forma predefinida. Para activar esta función, ponte en contacto con el servicio de asistencia.

Si estás utilizando cualquier otro proveedor SCM, aún puedes vincular manualmente la telemetría con tu código fuente. Para ello, carga los metadatos de tu repositorio con el comando datadog-ci git-metadata upload. Se requiere datadog-ci v2.10.0 o posterior.

Cuando se ejecuta datadog-ci git-metadata upload dentro de un repositorio Git, Datadog recibe la URL del repositorio, la función SHA de confirmación de la rama actual y una lista de rutas de archivos rastreados.

Ejecuta este comando para cada confirmación que necesites sincronizar con Datadog.

Validación

Para asegurarte de que los datos se están recopilando, ejecuta datadog-ci git-metadata upload en tu pipeline CI.

Puedes esperar ver el siguiente resultado:

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.

Etiquetar tu telemetría APM con información Git

Se requiere el Datadog Agent v7.35.0 o posterior.

Si ya tienes APM configurado, ve a Integrations > Link Source Code y configura la integración del código fuente para tus servicios de backend.

Tu telemetría debe estar etiquetada con información Git que vincule la versión de la aplicación en ejecución con un repositorio y una confirmación concretos.

Para los lenguajes compatibles, Datadog recomienda integrar información Git en los artefactos desplegados, que luego es extraída por las bibliotecas de rastreo de Datadog automáticamente.

Para otros lenguajes y configuraciones, puedes configurar el etiquetado de la telemetría tú mismo.

Integrar información Git en tus artefactos de compilación

Puedes integrar la URL del repositorio y el hash de confirmación en tu artefacto de compilación. Las bibliotecas de rastreo de Datadog utilizan esta información para añadir automáticamente las etiquetas (tags) correctas a la telemetría de tu servicio APM.

Selecciona uno de los siguientes lenguajes que sea compatible con la integración de información Git:

Se requiere la biblioteca del cliente Go versión 1.48.0 o posterior.

Contenedores

Si utilizas contenedores Docker, tienes tres opciones: utilizar Docker, utilizar la biblioteca de rastreo de Datadog o configurar tu aplicación con variables de entorno DD_GIT_*.

Opción 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    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. Add the following arguments to your Docker build command:

    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)
    
Opción 2: Biblioteca de rastreo de Datadog

Go embeds version control information in binaries since version 1.18. The Datadog tracing library uses this information to tag your telemetry with the latest commit SHA and repository URL.

Ensure your service meets the following requirements to use this approach:

  • Go version is 1.18 or later.
  • The service is built as a go module and the module path is your code’s repository URL.
Opción 3: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

Si utilizas la opción serverless, tienes tres opciones en función de la configuración de tu aplicación serverless.

Opción 1: Herramientas de Datadog
Datadog CLI tool
Use the datadog-ci client version 2.10.0 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.60.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.
Opción 2: Biblioteca de rastreo de Datadog

Go embeds version control information in binaries since version 1.18. The Datadog tracing library uses this information to tag your telemetry with the latest commit SHA and repository URL.

Ensure your service meets the following requirements to use this approach:

  • Go version is 1.18 or later.
  • The service is built as a go module and the module path is your code’s repository URL.
Opción 3: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

host

Si utilizas un host, tienes dos opciones.

Opción 1: Biblioteca de rastreo de Datadog

Go embeds version control information in binaries since version 1.18. The Datadog tracing library uses this information to tag your telemetry with the latest commit SHA and repository URL.

Ensure your service meets the following requirements to use this approach:

  • Go version is 1.18 or later.
  • The service is built as a go module and the module path is your code’s repository URL.
Opción 2: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Se requiere la biblioteca del cliente Python versión 1.12.0 o posterior.

Contenedores

Si utilizas contenedores Docker, tienes tres opciones: utilizar Docker, utilizar la biblioteca de rastreo de Datadog o configurar tu aplicación con variables de entorno DD_GIT_*.

Opción 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    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. Add the following arguments to your Docker build command:

    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)
    
Opción 2: Herramientas de configuración o archivo de parámetros unificados del proyecto Python

If your application is packaged with setuptools:

  1. Install the dd-trace package.
  2. Add import ddtrace.sourcecode.setuptools_auto as the first import to the setup.py file.
  3. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.

If your application is using a unified Python project settings file:

  1. Install the hatch-datadog-build-metadata plugin and configure it to embed git metadata. If a project already has URLs, reconfigure them as dynamic and move them to another configuration section. For more information, see the plugin source code.
  2. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.
Opción 3: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

Si utilizas la opción serverless, tienes tres opciones en función de la configuración de tu aplicación serverless.

Opción 1: Herramientas de Datadog
Datadog CLI tool
Use the datadog-ci client version 2.10.0 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.60.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.
Opción 2: Herramientas de configuración o archivo de parámetros unificados del proyecto Python

If your application is packaged with setuptools:

  1. Install the dd-trace package.
  2. Add import ddtrace.sourcecode.setuptools_auto as the first import to the setup.py file.
  3. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.

If your application is using a unified Python project settings file:

  1. Install the hatch-datadog-build-metadata plugin and configure it to embed git metadata. If a project already has URLs, reconfigure them as dynamic and move them to another configuration section. For more information, see the plugin source code.
  2. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.
Opción 3: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

host

Si utilizas un host, tienes dos opciones.

Opción 1: Herramientas de configuración o archivo de parámetros unificados del proyecto Python

If your application is packaged with setuptools:

  1. Install the dd-trace package.
  2. Add import ddtrace.sourcecode.setuptools_auto as the first import to the setup.py file.
  3. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.

If your application is using a unified Python project settings file:

  1. Install the hatch-datadog-build-metadata plugin and configure it to embed git metadata. If a project already has URLs, reconfigure them as dynamic and move them to another configuration section. For more information, see the plugin source code.
  2. Set the DD_MAIN_PACKAGE environment variable as the name of the primary Python package.
Opción 2: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Se requiere la biblioteca del cliente .NET versión 2.24.1 o posterior.

Como primer paso, asegúrate de que tus archivos .pdb se despliegan junto con tus ensamblados .NET (.dll o .exe) en la misma carpeta. A continuación, sigue el resto de las instrucciones en función de tu modelo de despliegue específico:

Contenedores

Si utilizas contenedores Docker, tienes tres opciones: utilizar Docker, utilizar la biblioteca de rastreo de Datadog o configurar tu aplicación con variables de entorno DD_GIT_*.

Opción 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    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. Add the following arguments to your Docker build command:

    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)
    

If you are using Microsoft SourceLink, Datadog can extract the git commit SHA and repository URL from your .NET assembly.

  1. Open your project’s file (.csproj) in an IDE and add a reference to one of the following NuGet packages, depending on where your git repository is hosted:
    ProviderMicrosoft SourceLink
    GitHubMicrosoft.SourceLink.GitHub
    BitbucketMicrosoft.SourceLink.Bitbucket.Git
    GitLabMicrosoft.SourceLink.GitLab
    Azure DevOpsMicrosoft.SourceLink.AzureRepos.Git
    Azure DevOps ServerMicrosoft.SourceLink.AzureDevOpsServer.Git
Opción 3: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

Si utilizas la opción serverless, tienes tres opciones en función de la configuración de tu aplicación serverless.

Opción 1: Herramientas de Datadog
Datadog CLI tool
Use the datadog-ci client version 2.10.0 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.60.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.

If you are using Microsoft SourceLink, Datadog can extract the git commit SHA and repository URL from your .NET assembly.

  1. Open your project’s file (.csproj) in an IDE and add a reference to one of the following NuGet packages, depending on where your git repository is hosted:
    ProviderMicrosoft SourceLink
    GitHubMicrosoft.SourceLink.GitHub
    BitbucketMicrosoft.SourceLink.Bitbucket.Git
    GitLabMicrosoft.SourceLink.GitLab
    Azure DevOpsMicrosoft.SourceLink.AzureRepos.Git
    Azure DevOps ServerMicrosoft.SourceLink.AzureDevOpsServer.Git
Opción 3: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

host

Si utilizas un host, tienes dos opciones: utilizar Microsoft SourceLink o configurar tu aplicación con variables de entorno DD_GIT_*.

If you are using Microsoft SourceLink, Datadog can extract the git commit SHA and repository URL from your .NET assembly.

  1. Open your project’s file (.csproj) in an IDE and add a reference to one of the following NuGet packages, depending on where your git repository is hosted:
    ProviderMicrosoft SourceLink
    GitHubMicrosoft.SourceLink.GitHub
    BitbucketMicrosoft.SourceLink.Bitbucket.Git
    GitLabMicrosoft.SourceLink.GitLab
    Azure DevOpsMicrosoft.SourceLink.AzureRepos.Git
    Azure DevOps ServerMicrosoft.SourceLink.AzureDevOpsServer.Git
Opción 2: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Se requiere la biblioteca de cliente de Node.js versión 3.21.0 o posterior.

Para aplicaciones de Node.js transpiladas (por ejemplo, TypeScript), asegúrate de generar y publicar mapas de fuentes con la aplicación desplegada, y de ejecutar Node.js con la opción --enable-source-maps. De lo contrario, los enlaces de código y fragmentos no funcionarán.

Contenedores

Si utilizas contenedores Docker, tienes dos opciones: utilizar Docker o configurar tu aplicación con variables de entorno DD_GIT_*.

Opción 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    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. Add the following arguments to your Docker build command:

    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)
    
Opción 2: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

Si utilizas la opción serverless, tienes dos opciones en función de la configuración de tu aplicación serverless.

Opción 1: Herramientas de Datadog
Datadog CLI tool
Use the datadog-ci client version 2.10.0 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.60.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.
Opción 2: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

host

Si utilizas un host, configura tu aplicación con variables de entorno DD_GIT_*.

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Se requiere la biblioteca del cliente Ruby versión 1.6.0 o posterior.

Contenedores

Si utilizas contenedores Docker, tienes dos opciones: utilizar Docker o configurar tu aplicación con la variable de entorno DD_TAGS.

Opción 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    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. Add the following arguments to your Docker build command:

    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)
    
Opción 2: Variable de entorno DD_TAGS

Configure your application with the DD_TAGS environment variable:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

Si utilizas la opción serverless, tienes dos opciones en función de la configuración de tu aplicación serverless.

Opción 1: Herramientas de Datadog
Datadog CLI tool
Use the datadog-ci client version 2.10.0 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.60.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.
Opción 2: Variable de entorno DD_TAGS

Configure your application with the DD_TAGS environment variable:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

host

Si utilizas un host, configura tu aplicación con la variable de entorno DD_TAGS.

Configure your application with the DD_TAGS environment variable:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Se requiere la biblioteca del cliente Java versión 1.12.0 o posterior.

Contenedores

Si utilizas contenedores Docker, tienes dos opciones: utilizar Docker o configurar tu aplicación con variables de entorno DD_GIT_*.

Opción 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    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. Add the following arguments to your Docker build command:

    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)
    
Opción 2: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Serverless

Si utilizas la opción serverless, tienes dos opciones en función de la configuración de tu aplicación serverless.

Opción 1: Herramientas de Datadog
Datadog CLI tool
Use the datadog-ci client version 2.10.0 or later. You must run the CLI tool in the same directory as the code repository.
Datadog Serverless Plugin
Use the plugin version 5.60.0 or later.
Datadog CDK Construct
Use the datadog-cdk-constructs version 0.8.5 or later for AWS CDK v1.
Use the datadog-cdk-constructs version 1.4.0 or later for AWS CDK v2.
Opción 2: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

host

Si utilizas un host, configura tu aplicación con variables de entorno DD_GIT_*.

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Se requiere la biblioteca del cliente PHP versión 1.2.0 o posterior.

Contenedores

Si utilizas contenedores Docker, tienes dos opciones: utilizar Docker o configurar tu aplicación con variables de entorno DD_GIT_*.

Opción 1: Docker
  1. Add the following lines to your application’s Dockerfile:

    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. Add the following arguments to your Docker build command:

    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)
    
Opción 2: Variables de entorno DD_GIT_*

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

host

Si utilizas un host, configura tu aplicación con variables de entorno DD_GIT_*.

Configure your application with the DD_GIT_* environment variables:

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

Replace <commitSha> with the commit SHA used to build your application. You can retrieve this by running git rev-parse HEAD at build time, and it needs to be passed into the runtime environment variables.

Compilación dentro de un contenedor Docker

Si tu proceso de compilación se ejecuta en CI dentro de un contenedor Docker, realiza los siguientes pasos para asegurarte de que la compilación puede acceder a la información Git:

  1. Añade el siguiente texto a tu archivo .dockerignore. Esto te asegura que el proceso de compilación pueda acceder a un subconjunto de la carpeta .git, lo que le permite determinar el hash de confirmación Git y la URL del repositorio.

    !.git/HEAD
    !.git/config
    !.git/refs
    
  2. Añade la siguiente línea de código a tu Dockerfile. Asegúrate de colocarla antes de que se ejecute la compilación real.

    COPY .git ./.git
    

Configuración del etiquetado de telemetría

Para los lenguajes no compatibles, utiliza las etiquetas git.commit.sha y git.repository_url para vincular los datos a una confirmación específica. Asegúrate de que la etiqueta git.repository_url no contiene protocolos. Por ejemplo, si la URL de tu repositorio es https://github.com/example/repo, el valor de la etiqueta git.repository_url debe ser github.com/example/repo.

Utilización

Enlaces a proveedores Git y fragmentos de código

En Error Tracking, puedes ver los enlaces de los marcos de stack tecnológico hasta su repositorio de origen.

  1. Ve a APM > Error Tracking.
  2. Haz clic en un problema. El panel Issue Details aparece a la derecha.
  3. En Último evento, si utilizas las integraciones GitHub o GitLab, haz clic en Connect to preview (Conectar para previsualizar) en los marcos de stack tecnológico. Puedes ver fragmentos de código en línea directamente en la traza de stack tecnológico. De lo contrario, puedes hacer clic en el botón View (Ver) a la derecha de un marco o seleccionar View file (Ver archivo), *View Git blame (Ver Git blame) o View commit (Ver commit) para ser redirigido a tu herramienta de gestión de código fuente.
Botón de visualización de repositorio con tres opciones (ver archivo, ver blame y ver confirmación) disponibles a la derecha de una stack trace de error en Error Tracking, junto con fragmentos de código en línea en la stack trace

En Continuous Profiler, puedes ver una vista previa del código fuente de los marcos de perfiles.

  1. Ve a APM > Profile Search.
  2. Pasa el cursor sobre un método en el gráfico de llamas.
  3. Si es necesario, pulsa Opt o Alt para habilitar la vista previa.
  4. Si utilizas las integraciones GitHub o GitLab, haz clic en Connect to preview (Conectar para previsualizar) para ver fragmentos de código en línea directamente en el gráfico de llamas.
Vista previa del código fuente en Continuous Profiler

También puedes ver los enlaces de los marcos de perfiles hasta su repositorio de origen. Esto es compatible con los perfiles desglosados por línea, método o archivo.

  1. Ve a APM > Profile Search.
  2. Pasa el cursor sobre un método en el gráfico de llamas. A la derecha aparece un icono con tres puntos con la etiqueta More actions.
  3. Haz clic en More actions > View in repo para abrir la traza en su repositorio de código fuente.
Enlace a GitHub desde Continuous Profiler

En Serverless Monitoring, puedes ver los enlaces de los errores en tus stack traces, asociadas a funciones Lambda, hasta su repositorio de origen.

  1. Ve a Infrastructure > Serverless y haz clic en la pestaña AWS.
  2. Haz clic en una función Lambda y luego en el botón Open Trace para una invocación con una stack trace asociada.
  3. Si utilizas las integraciones GitHub o GitLab, haz clic en Connect to preview (Conectar para previsualizar) en los marcos de stack tecnológico. Puedes ver fragmentos de código en línea directamente en la traza de stack tecnológico. De lo contrario, puedes hacer clic en el botón View (Ver) a la derecha de un marco o seleccionar View file (Ver archivo), *View Git blame (Ver Git blame) o View commit (Ver commit) para ser redirigido a tu herramienta de gestión de código fuente.

Puedes ver los enlaces de los tests fallidos a tu repositorio fuente en Optimización de test.

  1. Ve a Software Delivery > Test Optimization > Test Runs (Entrega de software > Optimización de test > Ejecuciones de test) y selecciona un test fallido.
  2. Si utilizas las integraciones GitHub o GitLab, haz clic en Connect to preview (Conectar para previsualizar) en los marcos de stack tecnológico. Puedes ver fragmentos de código en línea directamente en la traza de stack tecnológico. De lo contrario, puedes hacer clic en el botón View (Ver) a la derecha de un marco o seleccionar View file (Ver archivo), *View Git blame (Ver Git blame) o View commit (Ver commit) para ser redirigido a tu herramienta de gestión de código fuente.
Enlace a GitHub desde CI Visibility Explorer

Para obtener más información, consulta Mejora de los flujos de trabajo de los desarrolladores con Datadog.

Puedes ver los enlaces de los escaneos fallidos de Static Analysis y Software Composition Analysis a tu repositorio de fuentes en Code Security.

  1. Navega hasta Software Delivery > Code Security y selecciona un repositorio.
  2. En la vista Vulnerabilidades de código o Code Quality, haz clic en una vulnerabilidad o infracción de código. En la sección Detalles, si utilizas las integraciones GitHub, GitLab o Azure DevOps, haga clic en Connect to preview (Conectar para previsualizar). Puedes ver fragmentos de código en línea que resaltan las líneas exactas de código que desencadenaron la vulnerabilidad o infracción. De lo contrario, puedes hacer clic en el botón View (Ver) a la derecha de un marco o seleccionar View file (Ver archivo), *View Git blame (Ver Git blame) o View commit (Ver commit) para ser redirigido a tu herramienta de gestión de código fuente.
Enlace a GitHub desde la vista Code Security Code Vulnerabilities

Para más información, consulta la Documentación sobre Code Security.

Puedes ver los enlaces de los errores en los stack traces asociados de tus señales de seguridad a tu repositorio fuente en App and API Protection Monitoring.

  1. Navega a Security > App and API Protection (Seguridad > App and API Protection) y selecciona una señal de seguridad.
  2. Desplázate hasta la sección Traces, en la pestaña Related Signals, y haz clic en una stack trace asociada.
  3. Si utilizas las integraciones GitHub o GitLab, haz clic en Connect to preview (Conectar para previsualizar) en los marcos de stack tecnológico. Puedes ver fragmentos de código en línea directamente en la traza de stack tecnológico. De lo contrario, puedes hacer clic en el botón View (Ver) a la derecha de un marco o seleccionar View file (Ver archivo), *View Git blame (Ver Git blame) o View commit (Ver commit) para ser redirigido a tu herramienta de gestión de código fuente.
Enlace a GitHub desde App and API Protection Monitoring

Puedes ver los archivos de código fuente completos en Dynamic Instrumentation al crear o editar una instrumentación (log dinámico, métrica, tramo o etiquetas de tramo).

Crear nueva instrumentación

  1. Ve a APM > Dynamic Instrumentation.
  2. Selecciona Create New Instrumentation (Crear nueva instrumentación) y elige un servicio a instrumentar.
  3. Busca y selecciona un nombre de archivo o método de código fuente.

Ver o editar instrumentación

  1. Ve a APM > Dynamic Instrumentation.
  2. Selecciona una instrumentación existente en la lista y haz clic en View Events (Ver eventos).
  3. Selecciona la tarjeta de instrumentación para ver su localización en el código fuente.
Archivo de código fuente en Dynamic Instrumentation

Para más información, consulta la documentación de Dynamic Instrumentation.

Comentarios en solicitudes pull

Los comentarios en solicitudes pull están habilitados por defecto cuando se accede por primera vez a CI Visibility, si la integración GitHub o GitLab está instalada correctamente. Estas integraciones publican un comentario resumiendo los trabajos fallidos detectados en tu solicitud pull.

Comentario en solicitud pull que resume los trabajos fallidos detectados por CI Visibility

Para desactivar los comentarios en solicitudes pull para CI Visibility, ve a los parámetros de repositorios de CI Visibility.

Los comentarios en solicitudes pull están habilitados por defecto cuando se accede por primera vez a Code Security, si la integración GitHub, GitLab o Azure DevOps está instalada correctamente. Estas integraciones publican dos tipos de comentarios en tus solicitudes pull.

  1. Un único comentario que resume las nuevas infracciones detectadas en tu solicitud pull.
Comentario en solicitud pull que resume las nuevas infracciones detectadas por Code Security
  1. Comentarios en línea para cada infracción detectada en tu solicitud pull, colocados directamente en las líneas de código que generaron la infracción en el diff de la solicitud pull.
Comentario en línea de una infracción específica detectada por Code Security

Para desactivar los comentarios en solicitudes pull para Code Security, ve a los parámetros de repositorios de Code Security.

Los comentarios en solicitudes pull están habilitados por defecto cuando se accede por primera vez a Test Optimization, si la integración GitHub o GitLab está instalada correctamente. Estas integraciones publican un comentario resumiendo los tests fallidos o defectuosos detectados en tu solicitud pull.

Comentario en solicitud pull que resume los tests fallidos y defectuosos detectados por Test Optimization

Para desactivar los comentarios en solicitudes pull para Test Optimization, ve a los parámetros avanzados de repositorios de Test Optimization.

Referencias adicionales