Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solicitar una versión de paquete con repositorios ascendentes

El siguiente ejemplo muestra los posibles escenarios en los que un administrador de paquetes solicita un paquete de un repositorio de CodeCatalyst paquetes que tiene repositorios ascendentes.

En este ejemplo, un administrador de paquetes, como npm, solicita una versión de paquete desde un repositorio de paquetes denominado downstream, que tiene muchos repositorios ascendentes. Cuando se solicita el paquete, puede ocurrir lo siguiente:

El número máximo de repositorios ascendentes directos permitidos para un repositorio es 10. El número máximo de CodeCatalyst búsquedas en los repositorios cuando se solicita una versión de paquete es de 25.

Retención de paquetes de repositorios ascendentes

Si la versión de un paquete solicitada se encuentra en un repositorio ascendente, se conservará una referencia a la misma, que estará siempre disponible en el repositorio que la solicitó. Esto garantiza que tenga acceso a los paquetes en caso de que haya una interrupción inesperada del repositorio ascendente. La versión del paquete retenida no se ve afectada por ninguno de los siguientes factores:

Obtención de paquetes a través de una relación ascendente

CodeCatalyst puede buscar paquetes a través de varios repositorios enlazados denominados repositorios ascendentes. Si un repositorio de CodeCatalyst paquetes tiene una conexión ascendente a otro repositorio de CodeCatalyst paquetes que tiene una conexión ascendente a un repositorio de puerta de enlace, las solicitudes de paquetes que no estén en el repositorio ascendente se copian del repositorio externo. Por ejemplo, considere la siguiente configuración: un repositorio denominado repo-A tiene una conexión ascendente con el repositorio de puerta de enlace,. npm-public-registry-gateway npm-public-registry-gatewaytiene una conexión ascendente al repositorio público de paquetes,. https://npmjs.com

Si npm está configurado para usar el repo-A repositorio, la ejecución npm install inicia la copia de los paquetes desde https://npmjs.comdentro. npm-public-registry-gateway También se incluyen las versiones instaladasrepo-A. El siguiente ejemplo instala lodash.

$ npm config get registry
https://packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/
$ npm install lodash
+ lodash@4.17.20
added 1 package from 2 contributors in 6.933s

Tras ejecutar npm install, repo-A contiene solo la versión más reciente (lodash 4.17.20), ya que esa es la versión que npm ha obtenido desde repo-A.

Como npm-public-registry-gateway tiene una conexión ascendente externa a https://npmjs.com, todas las versiones de los paquetes desde las que se importan se https://npmjs.comalmacenan en él. npm-public-registry-gateway Estas versiones de paquetes podrían haber sido recuperadas por cualquier repositorio descendente con una conexión ascendente que llevase a npm-public-registry-gateway.

El contenido de npm-public-registry-gateway le permite ver todos los paquetes y las versiones de los paquetes que se han importado a https://npmjs.comlo largo del tiempo.

Retención de paquetes en repositorios intermedios

CodeCatalyst permite encadenar repositorios ascendentes. Por ejemplo, repo-A puede tener a repo-B como flujo ascendente y repo-B puede tener a repo-C como flujo ascendente. Esta configuración hace que las versiones del paquete en repo-B y repo-C estén disponibles de repo-A.

Cuando un administrador de paquetes se conecta al repositorio repo-A y obtiene una versión de paquete del repositorio repo-C, la versión del paquete no se conserva en el repositorio repo-B. La versión del paquete solo se conserva en el repositorio descendente más lejano; en este caso, repo-A. No se conservará en ningún repositorio intermedio. Esto también es válido para cadenas más largas; por ejemplo, si hubiera cuatro repositorios (repo-A, repo-B, repo-C y repo-D) y un administrador de paquetes conectado a repo-A extrajera una versión de paquete de repo-D, la versión del paquete se conservaría en repo-A, pero no en repo-B ni en repo-C.

El comportamiento de retención de paquetes es similar al de la extracción de una versión de paquete de un repositorio externo, con la diferencia de que la versión del paquete siempre se conserva en el repositorio de puerta de enlace que tenga la conexión ascendente directa al repositorio externo. Por ejemplo, repo-A tiene a repo-B como repositorio ascendente. repo-B tiene a npm-public-registry-gateway como repositorio ascendente, que tiene una conexión ascendente con el repositorio público npmjs.com; consulte el siguiente diagrama.

Si un administrador de paquetes conectado a repo-A solicita una versión de paquete específica, como lodash 4.17.20, y la versión del paquete no está en ninguno de los tres repositorios, se obtendrá de npmjs.com. Al obtener lodash 4.17.20, este se conserva en repo-A, ya que es el repositorio descendente más lejano, y en npm-public-registry-gateway, ya que tiene conectada la conexión ascendente al repositorio público externo (npmjs.com). lodash 4.17.20 no se conservará en repo-B porque es un repositorio intermedio.