Amazon non CodeCatalyst è più aperto a nuovi clienti. I clienti esistenti possono continuare a utilizzare il servizio normalmente. Per ulteriori informazioni, consulta Come migrare da CodeCatalyst.

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Richiedere una versione del pacchetto con repository upstream

L'esempio seguente mostra i possibili scenari in cui un gestore di pacchetti richiede un pacchetto da un repository di CodeCatalyst pacchetti con repository upstream.

Per questo esempio, un gestore di pacchetti, ad esempionpm, richiede una versione del pacchetto da un repository di pacchetti denominato downstream che ha più repository upstream. Quando viene richiesto il pacchetto, può verificarsi quanto segue:

Il numero massimo di repository upstream diretti consentiti per un repository è 10. Il numero massimo di archivi CodeCatalyst ricercati quando viene richiesta una versione del pacchetto è 25.

Conservazione dei pacchetti dai repository upstream

Se una versione del pacchetto richiesta viene trovata in un repository upstream, un riferimento ad essa viene mantenuto ed è sempre disponibile nel repository che l'ha richiesta. Ciò garantisce l'accesso ai pacchetti in caso di interruzione imprevista del repository upstream. La versione conservata del pacchetto non è influenzata da nessuno dei seguenti fattori:

Recupero dei pacchetti tramite una relazione upstream

CodeCatalyst può recuperare i pacchetti tramite più repository collegati chiamati repository upstream. Se un repository di CodeCatalyst pacchetti ha una connessione upstream a un altro repository di CodeCatalyst pacchetti che ha una connessione upstream a un repository gateway, le richieste di pacchetti non presenti nel repository upstream vengono copiate dal repository esterno. Ad esempio, si consideri la seguente configurazione: un repository denominato repo-A ha una connessione upstream al repository gateway,. npm-public-registry-gateway npm-public-registry-gatewayha una connessione upstream al repository pubblico dei pacchetti,. https://npmjs.com

Se npm è configurato per utilizzare il repo-A repository, l'esecuzione npm install avvia la copia dei pacchetti da in. https://npmjs.com npm-public-registry-gateway Vengono inoltre inserite le versioni installate. repo-A L'esempio seguente installa. 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

Dopo l'esecuzionenpm install, repo-A contiene solo la versione più recente (lodash 4.17.20) perché è la versione recuperata da npm from. repo-A

Poiché npm-public-registry-gateway ha una connessione upstream esterna a https://npmjs.com, tutte le versioni del pacchetto da cui vengono importate https://npmjs.com vengono archiviate in. npm-public-registry-gateway Queste versioni del pacchetto potrebbero essere state recuperate da qualsiasi repository downstream con una connessione upstream che porta a. npm-public-registry-gateway

Il contenuto di npm-public-registry-gateway fornisce un modo per visualizzare tutti i pacchetti e le versioni dei pacchetti importati nel tempo. https://npmjs.com

Conservazione dei pacchetti in archivi intermedi

CodeCatalyst consente di concatenare i repository upstream. Ad esempio, repo-A può avere repo-B come repository upstream e repo-B può avere repo-C come repository upstream. Questa configurazione rende le versioni del pacchetto inserite e disponibili da. repo-B repo-C repo-A

Quando un gestore di pacchetti si connette al repository repo-A e recupera una versione del pacchetto dal repositoryrepo-C, la versione del pacchetto non viene conservata nel repository. repo-B La versione del pacchetto viene conservata solo nel repository a valle più lontano, che in questo esempio è. repo-A Non viene conservata in nessun archivio intermedio. Questo vale anche per le catene più lunghe; ad esempio, se ci fossero quattro repository:repo-A, repo-B repo-Crepo-D, e e un gestore di pacchetti connesso a cui repo-A recuperare una versione del pacchettorepo-D, la versione del pacchetto verrebbe conservata ma non in or. repo-A repo-B repo-C

Il comportamento di conservazione dei pacchetti è simile quando si estrae una versione del pacchetto da un repository di pacchetti pubblico, tranne per il fatto che la versione del pacchetto viene sempre conservata nel repository gateway che ha la connessione diretta a monte al repository pubblico. Ad esempio, ha come repository upstreamrepo-A. repo-B repo-Bha npm-public-registry-gateway come repository upstream, che ha una connessione upstream al repository pubblico, npmjs.com; si veda il diagramma seguente.

Se un gestore di pacchetti connesso a repo-A richiede una versione specifica del pacchetto, ad esempio lodash 4.17.20, e la versione del pacchetto non è presente in nessuno dei tre repository, verrà recuperata da npmjs.com. Quando lodash 4.17.20 viene recuperato, viene mantenuto in repo-A quanto è il repository downstream più lontano e poiché ha la connessione upstream al repository esterno pubblico, npmjs.com. npm-public-registry-gateway lodash 4.17.20 repo-B non viene conservato in quanto si tratta di un repository intermedio.