Use variable for "dependency submission API" (#49191)

Author: mchammer01

Diff for: content/code-security/supply-chain-security/understanding-your-software-supply-chain/about-dependency-review.md

@@ -57,7 +57,7 @@ You can use the {% data variables.dependency-review.action_name %} in your repos
 
 By default, the {% data variables.dependency-review.action_name %} check will fail if it discovers any vulnerable packages. A failed check blocks a pull request from being merged when the repository owner requires the dependency review check to pass. For more information, see "[AUTOTITLE](/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches#require-status-checks-before-merging)."
 
-{% ifversion fpt or ghec or ghes %}The action uses the dependency review REST API to get the diff of dependency changes between the base commit and head commit. You can use the dependency review API to get the diff of dependency changes, including vulnerability data, between any two commits on a repository. For more information, see "[AUTOTITLE](/rest/dependency-graph#dependency-review)."{% endif %}{% ifversion dependency-review-submission-api %} The action also considers dependencies submitted via the dependency submission API. For more information about the dependency submission API, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."
+{% ifversion fpt or ghec or ghes %}The action uses the dependency review REST API to get the diff of dependency changes between the base commit and head commit. You can use the dependency review API to get the diff of dependency changes, including vulnerability data, between any two commits on a repository. For more information, see "[AUTOTITLE](/rest/dependency-graph#dependency-review)."{% endif %}{% ifversion dependency-review-submission-api %} The action also considers dependencies submitted via the {% data variables.dependency-submission-api.name %}. For more information about the {% data variables.dependency-submission-api.name %}, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."
 
 {% data reusables.dependency-review.works-with-submission-api-beta %}
 
@@ -71,29 +71,29 @@ You can configure the {% data variables.dependency-review.action_name %} to bett
 
 {% ifversion dependency-review-submission-api %}
 
-## Best practices for using the dependency review API and the dependency submission API together
+## Best practices for using the dependency review API and the {% data variables.dependency-submission-api.name %} together
 
 The dependency review API and the {% data variables.dependency-review.action_name %} both work by comparing dependency changes in a pull request with the state of your dependencies in the head commit of your target branch.
 
 If your repository only depends on statically defined dependencies in one of {% data variables.product.prodname_dotcom %}’s supported ecosystems, the dependency review API and the {% data variables.dependency-review.action_name %} work consistently.
 
-However, you may want your dependencies to be scanned during a build and then uploaded to the dependency submission API. In this case, there are some best practices you should follow to ensure that you don’t introduce a race condition when running the processes for the dependency review API and the dependency submission API, since it could result in missing data.
+However, you may want your dependencies to be scanned during a build and then uploaded to the {% data variables.dependency-submission-api.name %}. In this case, there are some best practices you should follow to ensure that you don’t introduce a race condition when running the processes for the dependency review API and the {% data variables.dependency-submission-api.name %}, since it could result in missing data.
 
-The best practices you should take will depend on whether you use {% data variables.product.prodname_actions %} to access the dependency submission API and the dependency review API, or whether you use direct API access.
+The best practices you should take will depend on whether you use {% data variables.product.prodname_actions %} to access the {% data variables.dependency-submission-api.name %} and the dependency review API, or whether you use direct API access.
 
-### Using GitHub Actions to access the dependency submission API and the dependency review API
+### Using GitHub Actions to access the {% data variables.dependency-submission-api.name %} and the dependency review API
 
-If you use {% data variables.product.prodname_actions %} to access the dependency submission API or the dependency review API:
+If you use {% data variables.product.prodname_actions %} to access the {% data variables.dependency-submission-api.name %} or the dependency review API:
    - Make sure you run all of your dependency submission actions in the same {% data variables.product.prodname_actions %} workflow as your {% data variables.dependency-review.action_name %}. This will give you control over the order of execution, and it will ensure that dependency review will always work.
    - If you do choose to run the {% data variables.dependency-review.action_name %} separately, for instance, as a required workflow, you should:
      - Set `retry-on-snapshot-warnings` to `true`.
      - Set `retry-on-snapshot-warnings-timeout` to slightly exceed the typical run time (in seconds) of your longest-running dependency submission action.
 
-### Using direct API access to the dependency submission API and the dependency review API
+### Using direct API access to the {% data variables.dependency-submission-api.name %} and the dependency review API
 
-If you don’t use {% data variables.product.prodname_actions %}, and your code relies on direct access to the dependency submission API and the dependency review API:
-   - Make sure you run the code that calls the dependency submission API first, and then run the code that calls the dependency review API afterwards.
-   - If you do choose to run the code for the dependency submission API and the dependency review API in parallel, you should implement a retry logic and note the following:
+If you don’t use {% data variables.product.prodname_actions %}, and your code relies on direct access to the {% data variables.dependency-submission-api.name %} and the dependency review API:
+   - Make sure you run the code that calls the {% data variables.dependency-submission-api.name %} first, and then run the code that calls the dependency review API afterwards.
+   - If you do choose to run the code for the {% data variables.dependency-submission-api.name %} and the dependency review API in parallel, you should implement a retry logic and note the following:
      - When there are snapshots missing for either side of the comparison, you will see an explanation for that in the `x-github-dependency-graph-snapshot-warnings` header (as a base64-encoded string). Therefore, if the header is non-empty, you should consider retrying.
      - Implement a retry logic with exponential backoff retries.
      - Implement a reasonable number of retries to account for the typical runtime of your dependency submission code.

Diff for: content/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph.md

@@ -45,12 +45,12 @@ For more information about configuration of the dependency graph, see "[AUTOTITL
 
 ## Dependencies included
 
-The dependency graph includes all the dependencies of a repository that are detailed in the manifest and lock files, or their equivalent, for supported ecosystems{% ifversion dependency-submission-api %}, as well as any dependencies that are submitted using the Dependency submission API (beta){% endif %}. This includes:
+The dependency graph includes all the dependencies of a repository that are detailed in the manifest and lock files, or their equivalent, for supported ecosystems{% ifversion dependency-submission-api %}, as well as any dependencies that are submitted using the {% data variables.dependency-submission-api.name %} (beta){% endif %}. This includes:
 
-- Direct dependencies, that are explicitly defined in a manifest or lock file {% ifversion dependency-submission-api %} or have been submitted using the Dependency submission API (beta){% endif %}
+- Direct dependencies, that are explicitly defined in a manifest or lock file {% ifversion dependency-submission-api %} or have been submitted using the {% data variables.dependency-submission-api.name %} (beta){% endif %}
 - Indirect dependencies of these direct dependencies, also known as transitive dependencies or sub-dependencies
 
-The dependency graph identifies indirect dependencies{% ifversion fpt or ghec %} only if they are defined in a lock file {% ifversion dependency-submission-api %}or have been submitted using the Dependency submission API (beta){% endif %}. For the most reliable graph, you should use lock files (or their equivalent) because they define exactly which versions of the direct and indirect dependencies you currently use. If you use lock files, you also ensure that all contributors to the repository are using the same versions, which will make it easier for you to test and debug code{% else %} from the lock files{% endif %}. {% ifversion dependency-submission-api %}If your ecosystem does not have lock files, you can use  pre-made actions that resolve transitive dependencies for many ecosystems. For more information, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api#using-pre-made-actions)."{% endif %}
+The dependency graph identifies indirect dependencies{% ifversion fpt or ghec %} only if they are defined in a lock file {% ifversion dependency-submission-api %}or have been submitted using the {% data variables.dependency-submission-api.name %} (beta){% endif %}. For the most reliable graph, you should use lock files (or their equivalent) because they define exactly which versions of the direct and indirect dependencies you currently use. If you use lock files, you also ensure that all contributors to the repository are using the same versions, which will make it easier for you to test and debug code{% else %} from the lock files{% endif %}. {% ifversion dependency-submission-api %}If your ecosystem does not have lock files, you can use  pre-made actions that resolve transitive dependencies for many ecosystems. For more information, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api#using-pre-made-actions)."{% endif %}
 
 For more information on how {% data variables.product.product_name %} helps you understand the dependencies in your environment, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/about-supply-chain-security)."
 
@@ -115,9 +115,9 @@ The recommended formats explicitly define which versions are used for all direct
 
 {% endnote %}
 
-{% ifversion dependency-submission-api %}You can use the Dependency submission API (beta) to add dependencies from the package manager or ecosystem of your choice to the dependency graph, even if the ecosystem is not in the supported ecosystem list above.{% endif %} {% data reusables.dependency-graph.dependency-submission-API-short %}
+{% ifversion dependency-submission-api %}You can use the {% data variables.dependency-submission-api.name %} (beta) to add dependencies from the package manager or ecosystem of your choice to the dependency graph, even if the ecosystem is not in the supported ecosystem list above.{% endif %} {% data reusables.dependency-graph.dependency-submission-API-short %}
 
-{% ifversion dependency-submission-api %}You will only get {% data variables.product.prodname_dependabot_alerts %} for dependencies that are from one of the [supported ecosystems](https://github.com/github/advisory-database#supported-ecosystems) of the {% data variables.product.prodname_advisory_database %}. For more information on the Dependency submission API, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."{% endif %}
+{% ifversion dependency-submission-api %}You will only get {% data variables.product.prodname_dependabot_alerts %} for dependencies that are from one of the [supported ecosystems](https://github.com/github/advisory-database#supported-ecosystems) of the {% data variables.product.prodname_advisory_database %}. For more information on the {% data variables.dependency-submission-api.name %}, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."{% endif %}
 
 ## Further reading
 

Diff for: content/code-security/supply-chain-security/understanding-your-software-supply-chain/exploring-the-dependencies-of-a-repository.md

@@ -54,7 +54,7 @@ Any direct and indirect dependencies that are specified in the repository's mani
 {% endif %}
 
 {% ifversion dependency-graph-repository-view-update %}
-Dependencies submitted to a project using the Dependency submission API (beta) will show which detector was used for their submission and when they were submitted.{% elsif ghes %}Dependencies submitted to a project using the Dependency submission API (beta), although also grouped by ecosystem, are shown separately from dependencies identified through manifest or lock files in the repository. These submitted dependencies appear in the dependency graph as "Snapshot dependencies" because they are submitted as a snapshot, or set, of dependencies.{% else %}{% endif %}{% ifversion dependency-submission-api %} For more information on using the dependency submission API, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."
+Dependencies submitted to a project using the {% data variables.dependency-submission-api.name %} (beta) will show which detector was used for their submission and when they were submitted.{% elsif ghes %}Dependencies submitted to a project using the {% data variables.dependency-submission-api.name %} (beta), although also grouped by ecosystem, are shown separately from dependencies identified through manifest or lock files in the repository. These submitted dependencies appear in the dependency graph as "Snapshot dependencies" because they are submitted as a snapshot, or set, of dependencies.{% else %}{% endif %}{% ifversion dependency-submission-api %} For more information on using the {% data variables.dependency-submission-api.name %}, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."
 {% endif %}
 
 If vulnerabilities have been detected in the repository, these are shown at the top of the view for users with access to {% data variables.product.prodname_dependabot_alerts %}.

Diff for: content/code-security/supply-chain-security/understanding-your-software-supply-chain/troubleshooting-the-dependency-graph.md

@@ -25,15 +25,15 @@ The dependency graph {% ifversion dependency-submission-api %}automatically{% en
 
 The dependency graph doesn't {% ifversion dependency-submission-api %}automatically{% endif %} include "loose" dependencies. "Loose" dependencies are individual files that are copied from another source and checked into the repository directly or within an archive (such as a ZIP or JAR file), rather than being referenced by in a package manager’s manifest or lockfile.
 
-{% ifversion dependency-submission-api %}However, you can use the Dependency submission API (beta) to add dependencies to a project's dependency graph, even if the dependencies are not declared in a manifest or lock file, such as dependencies resolved when a project is built.{% endif %} {% data reusables.dependency-graph.dependency-submission-API-short %} {% ifversion dependency-submission-api %}For more information on the Dependency submission API, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."{% endif %}
+{% ifversion dependency-submission-api %}However, you can use the {% data variables.dependency-submission-api.name %} (beta) to add dependencies to a project's dependency graph, even if the dependencies are not declared in a manifest or lock file, such as dependencies resolved when a project is built.{% endif %} {% data reusables.dependency-graph.dependency-submission-API-short %} {% ifversion dependency-submission-api %}For more information on the {% data variables.dependency-submission-api.name %}, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."{% endif %}
 
 **Check**: Is the missing dependency for a component that's not specified in the repository's manifest or lockfile?
 
 ## Does the dependency graph detect dependencies specified using variables?
 
 The dependency graph analyzes manifests as they’re pushed to {% data variables.product.prodname_dotcom %}. The dependency graph doesn't, therefore, have access to the build environment of the project, so it can't resolve variables used within manifests. If you use variables within a manifest to specify the name, or more commonly the version of a dependency, then that dependency will not {% ifversion dependency-submission-api %}automatically{% endif %} be included in the dependency graph.
 
-{% ifversion dependency-submission-api %}However, you can use the Dependency submission API (beta) to add dependencies to a project's dependency graph, even if the dependencies are only resolved when a project is built. For more information on the Dependency submission API, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."{% endif %}
+{% ifversion dependency-submission-api %}However, you can use the {% data variables.dependency-submission-api.name %} (beta) to add dependencies to a project's dependency graph, even if the dependencies are only resolved when a project is built. For more information on the {% data variables.dependency-submission-api.name %}, see "[AUTOTITLE](/code-security/supply-chain-security/understanding-your-software-supply-chain/using-the-dependency-submission-api)."{% endif %}
 
 **Check**: Is the missing dependency declared in the manifest by using a variable for its name or version?