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à.

Richiesta di 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 CodeCatalyst repository di pacchetti che dispone di repository upstream.

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

Il numero massimo di repository diretti upstream consentito per un repository è 10. Il numero massimo di CodeCatalyst ricerche nei repository quando viene richiesta una versione del pacchetto è 25.

Package retention dai repository upstream

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

Recupero dei pacchetti tramite una relazione a monte

CodeCatalyst può recuperare 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 nell'archivio upstream vengono copiate dal repository esterno. Ad esempio, considerate la seguente configurazione: un repository denominato repo-A ha una connessione upstream al repository del 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 dentro. https://npmjs.comnpm-public-registry-gateway Vengono inoltre inserite le versioni installate. repo-A L'esempio seguente installalodash.

$ 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 che è stata recuperata danpm. repo-A

Perché npm-public-registry-gateway dispone di una connessione upstream esterna a https://npmjs.com, tutte le versioni del pacchetto da cui vengono importate https://npmjs.comvengono archiviate in. npm-public-registry-gateway Queste versioni del pacchetto avrebbero potuto essere 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 repository intermedi

CodeCatalyst consente di concatenare 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 in repo-B e disponibili da. 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 nell'archivio. repo-B La versione del pacchetto viene conservata solo nell'archivio 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,, e repo-B repo-Crepo-D, e un gestore di pacchetti collegato al quale è stata repo-A recuperata una versione del pacchettorepo-D, la versione del pacchetto verrebbe conservata in ma non in o. repo-A repo-B repo-C

Il comportamento di conservazione dei pacchetti è simile quando si estrae una versione del pacchetto da un archivio pubblico di pacchetti, tranne per il fatto che la versione del pacchetto viene sempre conservata nell'archivio del gateway che ha la connessione diretta a monte all'archivio 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; vedi lo schema seguente.

Se un gestore di pacchetti connesso 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 si tratta del repository a valle più lontano e poiché dispone della connessione a monte al repository esterno pubblico, npmjs.com. npm-public-registry-gateway lodash 4.17.20 repo-B non viene mantenuto perché si tratta di un repository intermedio.