Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter Comment effectuer une migration depuis CodeCatalyst.

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 à un référentiel de CodeCatalyst packages qui possède 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 directs 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 vers un autre référentiel de CodeCatalyst packages doté d'une connexion en amont à un référentiel passerelle, les demandes concernant des 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 au référentiel de passerelle,npm-public-registry-gateway. npm-public-registry-gatewaydispose d'une connexion en amont au référentiel public de packages, https://npmjs.com.

S'npmil est configuré pour utiliser le repo-A référentiel, l'exécution npm install lance la copie des packages depuis https://npmjs.com versnpm-public-registry-gateway. Les versions installées sont également extraitesrepo-A. L'exemple suivant s'installe. 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, repo-A contient uniquement la dernière version (lodash 4.17.20) car c'est la version qui a été récupérée parnpm. repo-A

Parce qu'il npm-public-registry-gateway dispose d'une connexion externe en amont vers https://npmjs.com, toutes les versions de packages importées https://npmjs.com sont stockées dansnpm-public-registry-gateway. Ces versions de packages auraient pu être récupérées par n'importe quel référentiel en aval doté 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.com au fil du temps.

Conservation des packages dans des référentiels intermédiaires

CodeCatalyst vous permet de chaîner les référentiels en amont. Par exemple, repo-A peut avoir repo-B comme référentiel en amont et repo-B peut avoir repo-C comme référentiel en amont. Cette configuration rend les versions du package dans repo-B et repo-C disponibles à partir derepo-A.

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

Le comportement de conservation des packages est similaire lors de l'extraction d'une version de package depuis un référentiel public de packages, sauf que la version du package est toujours conservée dans le référentiel passerelle qui dispose d'une connexion directe en amont avec le référentiel public. Par exemple, repo-A has repo-B comme référentiel en amont. repo-Ba npm-public-registry-gateway comme référentiel en amont, qui dispose d'une connexion en amont au référentiel 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 depuis npmjs.com. Lorsque lodash 4.17.20 est récupéré, il est conservé car il s'agit du référentiel le plus en aval et repo-A npm-public-registry-gateway car il possède la 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.