Ahora la API de REST tiene control de versiones. Para obtener más información, consulta "Acerca del control de versiones de la API".

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

Usa la API de REST para enviar dependencias.

Acerca de los envíos de dependencias

Puedes usar la API REST para enviar dependencias para un proyecto. Esto te permite agregar dependencias, como las que se resuelven cuando se compila o crea software, a la característica de gráfico de dependencias de GitHub, lo que proporciona un panorama más completo de todos las dependencias del proyecto.

El gráfico de dependencias muestra las dependencias que envías mediante la API, además de las dependencias identificadas mediante archivos de bloqueo o de manifiesto en el repositorio (por ejemplo, un archivo package-lock.json en un proyecto de JavaScript). Para más información sobre cómo ver el gráfico de dependencias, consulta Explorar las dependencias de un repositorio.

Las dependencias enviadas recibirán Dependabot alerts y Dependabot security updates para cualquier vulnerabilidad conocida. Solo obtendrá Dependabot alerts para las dependencias que proceden de uno de los ecosistemas compatibles de GitHub Advisory Database. Para más información sobre estos ecosistemas, consulta Acerca de GitHub Advisory Database. En el caso de las dependencias transitivas enviadas a través de la API de envío de dependencias, Dependabot abrirá automáticamente las solicitudes de incorporación de cambios para actualizar la dependencia primaria, si hay disponible una actualización.

Las dependencias enviadas se mostrarán en la revisión de dependencias, pero no están disponibles en la información de dependencias de la organización.

Nota:

La API de revisión de dependencias y la API de envío de dependencias funcionan conjuntamente. Esto significa que la API de revisión de dependencias incluirá las dependencias enviadas a través de la API de envío de dependencias.

Puedes enviar dependencias en forma de instantánea. Una instantánea es un conjunto de dependencias asociadas a un SHA de confirmación y otros metadatos, que refleja el estado actual del repositorio para una confirmación. Puedes optar por usar acciones realizadas previamente o crear tus propias acciones para enviar las dependencias en el formato necesario cada vez que se compila el proyecto. Para más información, consulta Uso de la Dependency submission API.

Puedes enviar varios conjuntos de dependencias para su inclusión en el gráfico de dependencias. La API de REST usa la propiedad job.correlator y la categoría detector.name de la instantánea para garantizar que se muestren los envíos más recientes para cada flujo de trabajo. La propiedad correlator en sí es el campo principal que se usará para mantener la distinción de los envíos independientes. Una propiedad correlator de ejemplo podría ser una simple combinación de dos variables disponibles en las ejecuciones de acciones: <GITHUB_WORKFLOW> <GITHUB_JOB>.

El gráfico de dependencias puede obtener información sobre las dependencias de tres maneras diferentes: análisis estáticos, envío automático y envío manual. Un repositorio puede tener varios métodos configurados, lo que hace que el mismo manifiesto de paquete se examine varias veces, potencialmente con salidas diferentes de cada examen. El gráfico de dependencias usa lógica de desduplicación para analizar las salidas y priorizar la información más precisa para cada archivo de manifiesto.

El gráfico de dependencias muestra solo una instancia de cada archivo de manifiesto mediante las siguientes reglas de precedencia.

Los envíos de usuario tienen la prioridad más alta, ya que normalmente se crean durante las compilaciones de artefactos que tienen la información más completa.
- Si hay varias instantáneas manuales de diferentes detectores, se ordenan alfabéticamente por correlación y la primera usada.
- Si hay dos correladores con el mismo detector, se combinan las dependencias resueltas. Para obtener más información sobre los correladores y detectores, consulta Puntos de conexión de la API de REST para el envío de dependencias.
Los envíos automáticos tienen la segunda prioridad más alta, ya que también se crean durante las compilaciones de artefactos, pero los usuarios no los envían.
Los resultados de análisis estáticos se usan cuando no hay otros datos disponibles.

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 Obligatorio The account owner of the repository. The name is not case sensitive.
`repo` string Obligatorio The name of the repository without the `.git` extension. The name is not case sensitive.

Nombre, Tipo, Descripción

version integer Obligatorio

The version of the repository snapshot submission.

job object Obligatorio

Properties of job

Nombre, Tipo, Descripción
`id` string Obligatorio The external ID of the job.
`correlator` string Obligatorio 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 Obligatorio

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

ref string Obligatorio

The repository branch that triggered this snapshot.

detector object Obligatorio

A description of the detector used.

Properties of detector

Nombre, Tipo, Descripción
`name` string Obligatorio The name of the detector used.
`version` string Obligatorio The version of the detector used.
`url` string Obligatorio 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 Obligatorio

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 Obligatorio

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"

Si accedes a GitHub en GHE.com, reemplaza api.github.com por el subdominio dedicado de la empresa en api.SUBDOMAIN.ghe.com.

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" \
  https://api.github.com/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/[email protected]","dependencies":["@actions/http-client"]},"@actions/http-client":{"package_url":"pkg:/npm/%40actions/[email protected]","dependencies":["tunnel"]},"tunnel":{"package_url":"pkg:/npm/[email protected]"}}}}}'

Response

Status: 201

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