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

Quando un client (ad esempio, npm) richiede una versione del pacchetto da un CodeArtifact repository denominato my_repo che ha più repository upstream, può verificarsi quanto segue:

Quando si aggiungono repository upstream utilizzando il update-repository comando create-repository or, l'ordine in cui vengono passati al --upstreams parametro determina la loro priorità quando viene richiesta una versione del pacchetto. Specificate i repository upstream con --upstreams l'ordine che desiderate CodeArtifact utilizzare quando viene richiesta una versione del pacchetto. Per ulteriori informazioni, consulta Ordine di priorità del repository upstream.

Il numero massimo di repository diretti upstream consentito per un repository è 10. Poiché i repository diretti a monte possono avere anche repository diretti a monte propri, è CodeArtifact possibile cercare le versioni dei pacchetti in più di 10 repository. Il numero massimo di repository che vengono cercati quando viene CodeArtifact 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 downstream. La versione del pacchetto conservata non è influenzata da nessuno dei seguenti fattori:

Recupera i pacchetti tramite una relazione a monte

Se un CodeArtifact repository ha una relazione upstream con un repository che dispone di una connessione esterna, le richieste di pacchetti non presenti nel repository upstream vengono copiate dal repository esterno. Ad esempio, considera la seguente configurazione: un repository denominato ha un repository upstream denominato. repo-A repo-B repo-Bdispone di una connessione esterna a https://npmjs.com.

Se npm è configurato per utilizzare il repo-A repository, l'esecuzione npm install attiva la copia dei pacchetti da https://npmjs.com in. repo-B Vengono inoltre inserite le versioni installate. repo-A L'esempio seguente installalodash.

$ npm config get registry
https://my_domain-111122223333.d.codeartifact.us-west-2.amazonaws.com/npm/my-downstream-repo/
$ 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

aws codeartifact list-package-versions --repository repo-A --domain my_domain \
            --domain-owner 111122223333 --format npm --package lodash

Output di esempio:

{
    "package": "lodash",
    "format": "npm",
    "versions": [
        {
            "version": "4.17.15",
            "revision": "REVISION-1-SAMPLE-6C81EFF7DA55CC",
            "status": "Published"
        }
    ]
}

Poiché repo-B dispone di una connessione esterna a https://npmjs.com, tutte le versioni del pacchetto importate da https://npmjs.com vengono archiviate inrepo-B. Queste versioni del pacchetto avrebbero potuto essere recuperate da qualsiasi repository downstream con una relazione upstream con. repo-B

Il contenuto di repo-B fornisce un modo per vedere tutti i pacchetti e le versioni dei pacchetti importati da https://npmjs.com nel tempo. Ad esempio, per vedere tutte le versioni del lodash pacchetto importate nel tempo, è possibile utilizzare list-package-versions quanto segue.

aws codeartifact list-package-versions --repository repo-B --domain my_domain \
            --domain-owner 111122223333 --format npm --package lodash --max-results 5

Output di esempio:

{
    "package": "lodash",
    "format": "npm",
    "versions": [
        {
            "version": "0.10.0",
            "revision": "REVISION-1-SAMPLE-6C81EFF7DA55CC",
            "status": "Published"
        },
        {
            "version": "0.2.2",
            "revision": "REVISION-2-SAMPLE-6C81EFF7DA55CC",
            "status": "Published"
        },
        {
            "version": "0.2.0",
            "revision": "REVISION-3-SAMPLE-6C81EFF7DA55CC",
            "status": "Published"
        },
        {
            "version": "0.2.1",
            "revision": "REVISION-4-SAMPLE-6C81EFF7DA55CC",
            "status": "Published"
        },
        {
            "version": "0.1.0",
            "revision": "REVISION-5-SAMPLE-6C81EFF7DA55CC",
            "status": "Published"
        }
    ],
    "nextToken": "eyJsaXN0UGFja2FnZVZlcnNpb25zVG9rZW4iOiIwLjIuMiJ9"
}

Conservazione dei pacchetti in repository intermedi

CodeArtifact consente il concatenamento di repository upstream. Ad esempio, repo-A può avere repo-B come upstream e repo-B può avere repo-C come upstream. Questa configurazione rende le versioni del pacchetto in repo-B e repo-C disponibili da. 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 verrà conservata solo nell'archivio più a valle, in questo esempio. repo-A Non verrà conservata in nessun archivio intermedio. Questo vale anche per le catene più lunghe; ad esempio, se ci fossero quattro repositoryrepo-A, repo-Brepo-C, e repo-D e un gestore di pacchetti collegato da cui è 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 repository esterno, tranne per il fatto che la versione del pacchetto viene sempre conservata nel repository a cui è collegata la connessione esterna. Ad esempio, repo-A ha repo-B come upstream. repo-Bha repo-C come upstream e ha repo-C anche npmjs.com configurato come connessione esterna; vedere lo schema seguente.

Se un gestore di pacchetti connesso repo-A richiede una versione 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, verrà mantenuto in quanto si tratta del repository più a valle e repo-A poiché ha la connessione esterna a npmjs.com allegata. repo-C lodash 4.17.20 non verrà conservato in quanto si tratta di un repository intermedio. repo-B