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

Lorsqu'un client (par exemple, npm) demande une version de package à partir d'un CodeArtifact référentiel nommé my_repo contenant plusieurs référentiels en amont, les événements suivants peuvent se produire :

Lorsque vous ajoutez des référentiels en amont à l'aide de la update-repository commande create-repository ou, l'ordre dans lequel ils sont transmis au --upstreams paramètre détermine leur priorité lorsqu'une version de package est demandée. Spécifiez les référentiels en amont --upstreams dans l'ordre que vous CodeArtifact souhaitez utiliser lorsqu'une version de package est demandée. Pour plus d’informations, consultez Ordre de priorité du référentiel en amont.

Le nombre maximum de référentiels en amont autorisés pour un référentiel est de 10. Comme les référentiels en amont direct peuvent également avoir leurs propres référentiels en amont direct, ils CodeArtifact peuvent rechercher des versions de packages dans plus de 10 référentiels. Le nombre maximum de référentiels consultés CodeArtifact 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 en aval. La version du package conservée n'est affectée par aucun des éléments suivants :

Récupérez des packages via une relation en amont

Si un CodeArtifact référentiel entretient une relation en amont avec un référentiel doté d'une connexion externe, 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 un référentiel en amont nommérepo-B. repo-Bdispose d'une connexion externe à https://npmjs.com.

S'il npm est configuré pour utiliser le repo-A référentiel, l'exécution npm install déclenche la copie des packages depuis https://npmjs.com versrepo-B. Les versions installées sont également intégréesrepo-A. L'exemple suivant installe. lodash

$ 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

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

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

Exemple de sortie :

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

Comme il repo-B dispose d'une connexion externe à https://npmjs.com, toutes les versions de package importées depuis https://npmjs.com sont stockées dansrepo-B. Ces versions de package auraient pu être récupérées par n'importe quel dépôt en aval ayant une relation en amont avec. repo-B

Le contenu de repo-B fournit un moyen de voir tous les packages et versions de packages importés depuis https://npmjs.com au fil du temps. Par exemple, pour voir toutes les versions du lodash package importées au fil du temps, vous pouvez utiliser list-package-versions ce qui suit.

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

Exemple de sortie :

{
    "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"
}

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

CodeArtifact permet de chaîner des référentiels en amont. Par exemple, repo-A peut avoir repo-B comme amont et repo-B peut avoir repo-C comme 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 ne sera conservée que dans le référentiel le plus en aval, dans cet exemple,. repo-A Il ne sera conservé dans aucun dépôt intermédiaire. Cela est également vrai pour les chaînes plus longues ; par exemple, s'il y avait quatre référentiels repo-Arepo-B,repo-C, et repo-D et 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-A 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 externe, sauf que la version du package est toujours conservée dans le référentiel auquel la connexion externe est attachée. Par exemple, repo-A a repo-B en amont. repo-Bpossède repo-C une connexion amont et npmjs.com est repo-C également configuré en tant que connexion externe ; voir le schéma suivant.

Si un gestionnaire de packages connecté à repo-A demande une version de package, 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é car il s'agit du dépôt le plus en aval et repo-A repo-C car la connexion externe à npmjs.com y est attachée. lodash 4.17.20 ne sera pas conservé repo-B car il s'agit d'un dépôt intermédiaire.