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

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

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

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.

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. 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)
   

Option 2: Datadog Tracing Library

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.

Option 3: DD_GIT_* Environment Variables

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

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

Option 1: Datadog Tooling

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.

Option 2: Datadog Tracing Library

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.

Option 3: DD_GIT_* Environment Variables

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

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

Option 1: Datadog Tracing Library

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.

Option 2: DD_GIT_* Environment Variables

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.

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. 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)
   

Option 2: Setuptools or Unified Python Project Settings File

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.

Option 3: DD_GIT_* Environment Variables

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

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

Option 1: Datadog Tooling

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.

Option 2: Setuptools or Unified Python Project Settings File

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.

Option 3: DD_GIT_* Environment Variables

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

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

Option 1: Setuptools or Unified Python Project Settings File

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.

Option 2: DD_GIT_* Environment Variables

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.

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. 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)
   

Option 2: Microsoft SourceLink

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:

   Provider	Microsoft SourceLink
   GitHub	Microsoft.SourceLink.GitHub
   Bitbucket	Microsoft.SourceLink.Bitbucket.Git
   GitLab	Microsoft.SourceLink.GitLab
   Azure DevOps	Microsoft.SourceLink.AzureRepos.Git
   Azure DevOps Server	Microsoft.SourceLink.AzureDevOpsServer.Git

Option 3: DD_GIT_* Environment Variables

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

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

Option 1: Datadog Tooling

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.

Option 2: Microsoft SourceLink

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:

   Provider	Microsoft SourceLink
   GitHub	Microsoft.SourceLink.GitHub
   Bitbucket	Microsoft.SourceLink.Bitbucket.Git
   GitLab	Microsoft.SourceLink.GitLab
   Azure DevOps	Microsoft.SourceLink.AzureRepos.Git
   Azure DevOps Server	Microsoft.SourceLink.AzureDevOpsServer.Git

Option 3: DD_GIT_* Environment Variables

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

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

Option 1: Microsoft SourceLink

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:

   Provider	Microsoft SourceLink
   GitHub	Microsoft.SourceLink.GitHub
   Bitbucket	Microsoft.SourceLink.Bitbucket.Git
   GitLab	Microsoft.SourceLink.GitLab
   Azure DevOps	Microsoft.SourceLink.AzureRepos.Git
   Azure DevOps Server	Microsoft.SourceLink.AzureDevOpsServer.Git

Option 2: DD_GIT_* Environment Variables

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.

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. 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)
   

Option 2: DD_GIT_* Environment Variables

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

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

Option 1: Datadog Tooling

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.

Option 2: DD_GIT_* Environment Variables

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

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

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.

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. 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)
   

Option 2: DD_TAGS Environment Variable

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

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

Option 1: Datadog Tooling

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.

Option 2: DD_TAGS Environment Variable

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

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

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.

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. 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)
   

Option 2: DD_GIT_* Environment Variables

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

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

Option 1: Datadog Tooling

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.

Option 2: DD_GIT_* Environment Variables

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

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

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.

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. 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)
   

Option 2: DD_GIT_* Environment Variables

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

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

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.

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.

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.

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.

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.

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.

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.

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.

For more information, see the Dynamic Instrumentation documentation.

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.

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.

2. 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.

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.

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