Vue d'ensemble des packages - CodeArtifact
Formats de packages pris en chargePublication de packagesÉtat de la version du packageNom du package, version du package et normalisation du nom des actifs

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.

Vue d'ensemble des packages

Un package est un ensemble de logiciels et de métadonnées nécessaires pour résoudre les dépendances et installer le logiciel. Dans CodeArtifact, un package se compose d'un nom de package, d'un espace de noms facultatif tel que @types in@types/node, d'un ensemble de versions de package et de métadonnées au niveau du package telles que des balises npm.

Formats de packages pris en charge

AWS CodeArtifact prend en charge les formats de package Cargo, generic, Maven, npm, NuGetPyPI, Ruby et Swift.

Publication de packages

Vous pouvez publier de nouvelles versions de n'importe quel format de package pris en charge CodeArtifact dans un référentiel à l'aide d'outils tels que npm twineMaven,Gradle,nuget,, etdotnet.

Autorisations de publication

Votre AWS Identity and Access Management (IAM) utilisateur ou rôle doit être autorisé à publier dans le référentiel de destination. Les autorisations suivantes sont requises pour publier des packages :

  • Cargaison : codeartifact:PublishPackageVersion

  • générique : codeartifact:PublishPackageVersion

  • Maven : codeartifact:PublishPackageVersion et codeartifact:PutPackageMetadata

  • npm : codeartifact:PublishPackageVersion

  • NuGet: codeartifact:PublishPackageVersion et codeartifact:ReadFromRepository

  • Python : codeartifact:PublishPackageVersion

  • Rubis : codeartifact:PublishPackageVersion

  • Rapide : codeartifact:PublishPackageVersion

Dans la liste d'autorisations précédente, votre IAM politique doit spécifier la package ressource pour les codeartifact:PutPackageMetadata autorisations codeartifact:PublishPackageVersion et. Il doit également spécifier la repository ressource pour l'codeartifact:ReadFromRepositoryautorisation.

Pour plus d'informations sur les autorisations d' CodeArtifactentrée, consultezAWS CodeArtifact référence aux autorisations.

Remplacement des actifs du package

Vous ne pouvez pas republier une ressource de package qui existe déjà avec un contenu différent. Supposons, par exemple, que vous ayez déjà publié un package Maven contenant un JAR actifmypackage-1.0.jar. Vous ne pouvez publier à nouveau cette ressource que si la somme de contrôle des anciennes et des nouvelles ressources est identique. Pour republier la même ressource avec un nouveau contenu, supprimez d'abord la version du package à l'aide de la delete-package-versions commande. Toute tentative de republication du même nom de ressource avec un contenu différent entraînera une erreur de conflit HTTP 409.

Pour les formats de package qui prennent en charge plusieurs actifs (générique, PyPI et Maven), vous pouvez ajouter de nouveaux actifs portant des noms différents à une version de package existante, en supposant que vous disposez des autorisations requises. Pour les packages génériques, vous pouvez ajouter de nouveaux actifs tant que la version du package est dans l'Unfinishedétat. Étant donné que npm ne prend en charge qu'un seul actif par version de package, pour modifier une version de package publiée de quelque manière que ce soit, vous devez d'abord la supprimer à l'aide delete-package-versions de.

Si vous essayez de republier une ressource qui existe déjà (par exemple,mypackage-1.0.jar) et que le contenu de la ressource publiée et de la nouvelle ressource est identique, l'opération aboutira car elle est idempotente.

Packages privés et référentiels publics

CodeArtifact ne publie pas les packages stockés dans CodeArtifact des référentiels publics tels que npmjs.com ou Maven Central. CodeArtifact importe des packages depuis des référentiels publics vers un CodeArtifact référentiel, mais ne déplace jamais les packages dans l'autre sens. Les packages que vous publiez dans CodeArtifact des référentiels restent privés et ne sont disponibles que pour les AWS comptes, les rôles et les utilisateurs auxquels vous avez accordé l'accès.

Publication de versions de packages corrigées

Parfois, vous souhaiterez peut-être publier une version de package modifiée, éventuellement disponible dans un dépôt public. Par exemple, vous avez peut-être découvert un bogue dans une dépendance d'application critique appeléemydep 1.1, et vous devez le corriger avant que le fournisseur du package ne puisse examiner et accepter la modification. Comme décrit précédemment, vous CodeArtifact empêche de publier mydep 1.1 dans votre CodeArtifact référentiel si le référentiel public est accessible depuis votre CodeArtifact référentiel via des référentiels en amont et une connexion externe.

Pour contourner ce problème, publiez la version du package dans un autre CodeArtifact référentiel où le référentiel public n'est pas accessible. Utilisez ensuite le copy-package-versions API pour copier la version corrigée de dans mydep 1.1 le CodeArtifact référentiel d'où vous allez la consommer.

Limites de taille des ressources pour la publication

La taille maximale d'une ressource de package pouvant être publiée est limitée par le quota maximal de taille de fichier de ressource indiqué dansQuotas dans AWS CodeArtifact. Par exemple, vous ne pouvez pas publier une roue Maven JAR ou Python dont la taille est supérieure au quota maximal de votre fichier de ressources actuel. Si vous devez y stocker des actifs plus importants CodeArtifact, demandez une augmentation de quota.

Outre le quota maximal de taille de fichier de ressource, la taille maximale d'une demande de publication pour les packages npm est de 2 Go. Cette limite est indépendante du quota maximal de taille du fichier de ressources et ne peut pas être augmentée avec une augmentation du quota. Dans une demande de publication npm (HTTPPUT), les métadonnées du package et le contenu de l'archive tar du package npm sont regroupés. De ce fait, la taille maximale réelle d'un package npm pouvant être publié varie et dépend de la taille des métadonnées incluses.

Note

Les packages npm publiés sont limités à une taille maximale inférieure à 2 Go.

Latence de publication

Les versions de package publiées dans un CodeArtifact référentiel peuvent souvent être téléchargées en moins d'une seconde. Par exemple, si vous publiez une version de package npm sur CodeArtifact withnpm publish, cette version devrait être disponible pour une npm install commande en moins d'une seconde. Cependant, la publication peut être incohérente et peut parfois prendre plus de temps. Si vous devez utiliser une version du package immédiatement après la publication, réessayez pour vous assurer que le téléchargement est fiable. Par exemple, après avoir publié la version du package, répétez le téléchargement jusqu'à trois fois si la version du package qui vient d'être publiée n'est pas initialement disponible lors de la première tentative de téléchargement.

Note

L'importation d'une version de package depuis un dépôt public prend généralement plus de temps que la publication. Pour de plus amples informations, veuillez consulter Latence inférieure inférieure inférieure inférieure inférieure.

État de la version du package

Chaque version de package CodeArtifact possède un statut qui décrit l'état actuel et la disponibilité de la version du package. Vous pouvez modifier le statut de la version du package dans AWS CLI etSDK. Pour de plus amples informations, veuillez consulter État de version du package de mise à jour.

Les valeurs possibles pour l'état de la version du package sont les suivantes :

  • Publié — La version du package a été publiée avec succès et peut être demandée à l'aide d'un gestionnaire de packages. La version du package sera incluse dans les listes de versions de package renvoyées aux gestionnaires de packages, par exemple dans la sortie denpm view <package-name> versions. Toutes les ressources de la version du package sont disponibles dans le référentiel.

  • Inachevé : le client a chargé une ou plusieurs ressources pour une version de package, mais ne les a pas finalisées en les transférant dans l'Publishedétat. Actuellement, seules les versions génériques et les versions de package Maven peuvent avoir un statut deUnfinished. Pour les packages Maven, cela peut se produire lorsque le client télécharge une ou plusieurs ressources pour une version de package mais ne publie pas de maven-metadata.xml fichier pour le package qui inclut cette version. Lorsqu'une version de package Maven est inachevée, elle ne sera pas incluse dans les listes de versions renvoyées aux clients et mvn ne pourra donc pas être utilisée dans le cadre d'une compilation. gradle Les packages génériques peuvent être délibérément conservés dans Unfinished cet état en fournissant l'unfinishedindicateur lors de l'appel du PublishPackageVersionAPI. Un package générique peut être changé en Published état en omettant le unfinished drapeau ou en appelant le UpdatePackageVersionsStatusAPI.

  • Non répertorié — Les ressources de la version du package peuvent être téléchargées depuis le référentiel, mais la version du package n'est pas incluse dans la liste des versions renvoyées aux gestionnaires de packages. Par exemple, pour un package npm, la sortie de n'npm view <package-name> versionsinclura pas la version du package. Cela signifie que la logique de résolution des dépendances de npm ne sélectionnera pas la version du package car celle-ci n'apparaît pas dans la liste des versions disponibles. Toutefois, si la version du package non répertorié est déjà référencée dans un npm package-lock.json fichier, elle peut toujours être téléchargée et installée, par exemple lors de son exécutionnpm ci.

  • Archivé — Les ressources de la version du package ne peuvent plus être téléchargées. La version du package ne sera pas incluse dans la liste des versions renvoyées aux gestionnaires de packages. Comme les actifs ne sont pas disponibles, la consommation de la version du package par les clients est bloquée. Si la version de votre application dépend d'une version mise à jour vers Archivé, la version sera interrompue, en supposant que la version du package n'a pas été mise en cache localement. Vous ne pouvez pas utiliser un gestionnaire de packages ou un outil de génération pour republier une version de package archivée car elle est toujours présente dans le référentiel, mais vous pouvez redéfinir le statut de la version du package sur Non répertorié ou Publié avec le. UpdatePackageVersionsStatus API

  • Supprimé — La version du package n'apparaît pas dans les listes et les ressources ne peuvent pas être téléchargées depuis le référentiel. La principale différence entre Disposé et Archivé est que lorsque le statut est Disposé, les actifs de la version du package seront définitivement supprimés par CodeArtifact. Pour cette raison, vous ne pouvez pas déplacer une version de package du statut Disposé vers Archivé, Non répertorié ou Publié. La version du package ne peut plus être utilisée car les actifs ont été supprimés. Une fois qu'une version du package a été marquée comme supprimée, le stockage des actifs du package ne vous sera plus facturé.

Les versions de package de tous les statuts seront renvoyées par défaut lors d' list-package-versionsun appel sans --status paramètre.

Outre les états listés précédemment, une version de package peut également être supprimée à l'aide du DeletePackageVersionsAPI. Une fois supprimée, une version de package ne figure plus dans le référentiel et vous pouvez librement republier cette version de package à l'aide d'un gestionnaire de packages ou d'un outil de génération. Après la suppression d'une version de package, le stockage des actifs de cette version de package ne vous sera plus facturé.

Nom du package, version du package et normalisation du nom des actifs

CodeArtifact normalise les noms des packages, les versions des packages et les noms des actifs avant de les stocker, ce qui signifie que les noms ou les versions CodeArtifact peuvent être différents du nom ou de la version fournis lors de la publication du package. Pour plus d'informations sur la façon dont les noms et les versions sont normalisés CodeArtifact pour chaque type de package, consultez la documentation suivante :

CodeArtifact n'effectue pas de normalisation sur les autres formats de package.