Puntos de conexión de la API de REST para el envío de dependencias

About dependency submissions

You can use the REST API to submit dependencies for a project. This enables you to add dependencies, such as those resolved when software is compiled or built, to GitHub's dependency graph feature, providing a more complete picture of all of your project's dependencies.

The dependency graph shows any dependencies you submit using the API in addition to any dependencies that are identified from manifest or lock files in the repository (for example, a package-lock.json file in a JavaScript project). For more information about viewing the dependency graph, see Exploring the dependencies of a repository.

Submitted dependencies will receive Dependabot alerts and Dependabot security updates for any known vulnerabilities. You will only get Dependabot alerts for dependencies that are from one of the supported ecosystems for the GitHub Advisory Database. For more information about these ecosystems, see About the GitHub Advisory database. For transitive dependencies submitted via the dependency submission API, Dependabot will automatically open pull requests to update the parent dependency, if an update is available.

Submitted dependencies will be shown in dependency review, but are not available in your organization's dependency insights.

Note

The dependency review API and the dependency submission API work together. This means that the dependency review API will include dependencies submitted via the dependency submission API.

You can submit dependencies in the form of a snapshot. A snapshot is a set of dependencies associated with a commit SHA and other metadata, that reflects the current state of your repository for a commit. You can choose to use pre-made actions or create your own actions to submit your dependencies in the required format each time your project is built. For more information, see Using the dependency submission API.

You can submit multiple sets of dependencies to be included in your dependency graph. The REST API uses the job.correlator property and the detector.name category of the snapshot to ensure the latest submissions for each workflow get shown. The correlator property itself is the primary field you will use to keep independent submissions distinct. An example correlator could be a simple combination of two variables available in actions runs: <GITHUB_WORKFLOW> <GITHUB_JOB>.

Create a snapshot of dependencies for a repository

Create a new snapshot of a repository's dependencies.

The authenticated user must have access to the repository.

OAuth app tokens and personal access tokens (classic) need the repo scope to use this endpoint.

Tokens de acceso específicos para "Create a snapshot of dependencies for a repository"

Este punto de conexión funciona con los siguientes tipos de token pormenorizados:

El token pormenorizado debe tener el siguiente conjunto de permisos:

"Contents" repository permissions (write)

Parámetros para "Create a snapshot of dependencies for a repository"

Encabezados
Nombre, Tipo, Descripción
`accept` string Setting to `application/vnd.github+json` is recommended.

Parámetros de la ruta de acceso
Nombre, Tipo, Descripción
`owner` string Requerido The account owner of the repository. The name is not case sensitive.
`repo` string Requerido The name of the repository without the `.git` extension. The name is not case sensitive.

Nombre, Tipo, Descripción

version integer Requerido

The version of the repository snapshot submission.

job object Requerido

Properties of job

Nombre, Tipo, Descripción
`id` string Requerido The external ID of the job.
`correlator` string Requerido Correlator provides a key that is used to group snapshots submitted over time. Only the "latest" submitted snapshot for a given combination of `job.correlator` and `detector.name` will be considered when calculating a repository's current dependencies. Correlator should be as unique as it takes to distinguish all detection runs for a given "wave" of CI workflow you run. If you're using GitHub Actions, a good default value for this could be the environment variables GITHUB_WORKFLOW and GITHUB_JOB concatenated together. If you're using a build matrix, then you'll also need to add additional key(s) to distinguish between each submission inside a matrix variation.
`html_url` string The url for the job.

sha string Requerido

The commit SHA associated with this dependency snapshot. Maximum length: 40 characters.

ref string Requerido

The repository branch that triggered this snapshot.

detector object Requerido

A description of the detector used.

Properties of detector

Nombre, Tipo, Descripción
`name` string Requerido The name of the detector used.
`version` string Requerido The version of the detector used.
`url` string Requerido The url of the detector used.

metadata object

User-defined metadata to store domain-specific information limited to 8 keys with scalar values.

manifests object

A collection of package manifests, which are a collection of related dependencies declared in a file or representing a logical group of dependencies.

Properties of manifests

Nombre, Tipo, Descripción

key object

A user-defined key to represent an item in manifests.

Properties of key

Nombre, Tipo, Descripción

name string Requerido

The name of the manifest.

file object

Properties of file

Nombre, Tipo, Descripción
`source_location` string The path of the manifest file relative to the root of the Git repository.

metadata object

User-defined metadata to store domain-specific information limited to 8 keys with scalar values.

resolved object

A collection of resolved package dependencies.

Properties of resolved

Nombre, Tipo, Descripción

key object

A user-defined key to represent an item in resolved.

Properties of key

Nombre, Tipo, Descripción
`package_url` string Package-url (PURL) of dependency. See https://github.com/package-url/purl-spec for more details.
`metadata` object User-defined metadata to store domain-specific information limited to 8 keys with scalar values.
`relationship` string A notation of whether a dependency is requested directly by this manifest or is a dependency of another dependency. Puede ser uno de los siguientes: `direct`, `indirect`
`scope` string A notation of whether the dependency is required for the primary build artifact (runtime) or is only used for development. Future versions of this specification may allow for more granular scopes. Puede ser uno de los siguientes: `runtime`, `development`
`dependencies` array of strings Array of package-url (PURLs) of direct child dependencies.

scanned string Requerido

The time at which the snapshot was scanned.

Códigos de estado de respuesta HTTP para "Create a snapshot of dependencies for a repository"

status code	Descripción
`201`	Created

Ejemplos de código para "Create a snapshot of dependencies for a repository"

Ejemplo de solicitud

post/repos/{owner}/{repo}/dependency-graph/snapshots

curl -L \
  -X POST \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2022-11-28" \
  http(s)://HOSTNAME/api/v3/repos/OWNER/REPO/dependency-graph/snapshots \
  -d '{"version":0,"sha":"ce587453ced02b1526dfb4cb910479d431683101","ref":"refs/heads/main","job":{"correlator":"yourworkflowname_youractionname","id":"yourrunid"},"detector":{"name":"octo-detector","version":"0.0.1","url":"https://github.com/octo-org/octo-repo"},"scanned":"2022-06-14T20:25:00Z","manifests":{"package-lock.json":{"name":"package-lock.json","file":{"source_location":"src/package-lock.json"},"resolved":{"@actions/core":{"package_url":"pkg:/npm/%40actions/core@1.1.9","dependencies":["@actions/http-client"]},"@actions/http-client":{"package_url":"pkg:/npm/%40actions/http-client@1.0.7","dependencies":["tunnel"]},"tunnel":{"package_url":"pkg:/npm/tunnel@0.0.6"}}}}}'

Response

Status: 201

{
  "id": 12345,
  "created_at": "2018-05-04T01:14:52Z",
  "message": "Dependency results for the repo have been successfully updated.",
  "result": "SUCCESS"
}