Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Demande d'une version de package avec des référentiels en amont

L'exemple suivant montre les scénarios possibles lorsqu'un gestionnaire de packages demande un package à partir d'un référentiel de CodeCatalyst packages contenant des référentiels en amont.

Dans cet exemple, un gestionnaire de packages, tel quenpm, demande une version de package à partir d'un référentiel de packages nommé downstream qui possède plusieurs référentiels en amont. Lorsque le package est demandé, les événements suivants peuvent se produire :

Le nombre maximum de référentiels en amont autorisés pour un référentiel est de 10. Le nombre maximum de CodeCatalyst recherches dans les référentiels lorsqu'une version de package est demandée est de 25.

Conservation des packages depuis les référentiels en amont

Si une version de package demandée est trouvée dans un référentiel en amont, une référence à celle-ci est conservée et est toujours disponible dans le référentiel qui l'a demandée. Cela garantit que vous avez accès à vos packages en cas de panne inattendue du référentiel en amont. La version du package conservée n'est affectée par aucun des éléments suivants :

Récupération de packages via une relation en amont

CodeCatalyst peut récupérer des packages via plusieurs référentiels liés appelés référentiels en amont. Si un référentiel de CodeCatalyst packages possède une connexion en amont à un autre référentiel de CodeCatalyst packages doté d'une connexion en amont à un référentiel de passerelle, les demandes de packages ne figurant pas dans le référentiel en amont sont copiées depuis le référentiel externe. Par exemple, considérez la configuration suivante : un référentiel nommé repo-A possède une connexion en amont avec le référentiel de passerelle,npm-public-registry-gateway. npm-public-registry-gatewaydispose d'une connexion en amont vers le référentiel public de packages, https://npmjs.com.

S'il npm est configuré pour utiliser le repo-A référentiel, l'exécution npm install initie la copie des packages depuis et https://npmjs.comversnpm-public-registry-gateway. Les versions installées sont également intégréesrepo-A. L'exemple suivant permet d'installer. 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

Après l'exécutionnpm install, ne repo-A contient que la dernière version (lodash 4.17.20) car c'est la version qui a été récupérée parnpm. repo-A

Étant donné qu'il npm-public-registry-gateway dispose d'une connexion externe en amont à https://npmjs.com, toutes les versions de package importées https://npmjs.comsont stockées dansnpm-public-registry-gateway. Ces versions de package auraient pu être récupérées par n'importe quel dépôt en aval disposant d'une connexion en amont menant ànpm-public-registry-gateway.

Le contenu de npm-public-registry-gateway vous permet de voir tous les packages et versions de packages importés https://npmjs.comau fil du temps.

Rétention des packages dans des référentiels intermédiaires

CodeCatalyst vous permet d'enchaîner les référentiels en amont. Par exemple, il repo-A peut être repo-B utilisé comme référentiel en amont repo-B ou en repo-C tant que référentiel en amont. Cette configuration permet aux versions du package d'être intégrées repo-B et repo-C disponibles auprès derepo-A.

Lorsqu'un gestionnaire de packages se connecte au référentiel repo-A et récupère une version de package à partir du référentielrepo-C, la version du package n'est pas conservée dans le référentielrepo-B. La version du package n'est conservée que dans le référentiel le plus en aval, c'est-à-dire dans cet exemple. repo-A Il n'est conservé dans aucun référentiel intermédiaire. Cela est également vrai pour les chaînes plus longues ; par exemple, s'il y avait quatre référentiels :repo-A, repo-Brepo-C, etrepo-D, et repo-A qu'un gestionnaire de packages était connecté pour repo-A récupérer une version de packagerepo-D, la version du package serait conservée dans ou pas dans repo-B ou. repo-C

Le comportement de rétention des packages est similaire lors de l'extraction d'une version de package depuis un référentiel de packages public, sauf que la version du package est toujours conservée dans le référentiel de passerelle qui dispose d'une connexion directe en amont avec le référentiel public. Par exemple, repo-A a repo-B comme référentiel en amont. repo-Bdispose npm-public-registry-gateway d'un dépôt en amont, qui dispose d'une connexion en amont au dépôt public, npmjs.com ; voir le schéma ci-dessous.

Si un gestionnaire de packages connecté à repo-A demande une version de package spécifique, lodash 4.17.20 par exemple, et que la version du package n'est présente dans aucun des trois référentiels, elle sera récupérée sur npmjs.com. Lorsque lodash 4.17.20 est récupéré, il est conservé repo-A car il s'agit du dépôt le plus en aval et npm-public-registry-gateway puisqu'il dispose d'une connexion en amont au référentiel externe public, npmjs.com. lodash 4.17.20 n'est pas conservé repo-B car il s'agit d'un dépôt intermédiaire.