Amazon n' CodeCatalyst est plus ouvert aux nouveaux clients. Les clients existants peuvent continuer à utiliser le service normalement. Pour de plus amples informations, veuillez consulter [Comment effectuer une migration depuis CodeCatalyst](migration.md).
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.
# Publiez et partagez des progiciels dans CodeCatalyst
Amazon CodeCatalyst propose un service de référentiel de packages entièrement géré qui permet à votre équipe de développement de stocker et de partager facilement en toute sécurité les packages logiciels utilisés pour le développement d'applications. Ces packages sont stockés dans des référentiels de packages, qui sont créés et organisés au sein de projets dans CodeCatalyst.
Un référentiel de packages unique peut stocker des packages de tous les types de packages pris en charge. CodeCatalyst prend en charge les formats de package suivants :
+ npm
+ Maven
+ NuGet
+ Python
Les packages d'un référentiel de packages peuvent être découverts et partagés entre les membres du projet qui contient le référentiel.
Pour publier des packages et utiliser des packages depuis un référentiel, configurez un gestionnaire de packages de manière à utiliser le point de terminaison (URL) du référentiel. Vous pouvez ensuite utiliser le gestionnaire de packages pour publier des packages dans le référentiel. Vous pouvez utiliser des gestionnaires de packages tels que Maven, Gradle, npm, yarn, nuget, dotnet, pip et twine.
Vous pouvez également configurer des CodeCatalyst flux de travail pour utiliser des référentiels de CodeCatalyst packages. Pour plus d'informations sur l'utilisation de packages dans les flux de travail, consultez[Connecter les référentiels de packages aux flux de travail](workflows-packages.md).
Vous pouvez mettre les packages d'un référentiel de packages à la disposition d'un autre référentiel du même projet en l'ajoutant en tant que référentiel en amont. Toutes les versions de package disponibles dans le référentiel en amont sont également disponibles dans le référentiel en aval. Pour de plus amples informations, veuillez consulter [Configuration et utilisation de référentiels en amont](packages-upstream-repositories.md).
Vous pouvez mettre des packages open source à la disposition de votre CodeCatalyst dépôt en créant un type spécial de référentiel appelé **passerelle**. La remontée vers un dépôt passerelle vous permet de consommer des packages provenant de référentiels publics populaires tels que npmjs.com et pypi.org, et de les mettre automatiquement en cache dans votre référentiel. CodeCatalyst Pour de plus amples informations, veuillez consulter [Connexion à des référentiels externes publics](packages-connect-external.md).
**Topics**
+ [Concepts de package](packages-concepts.md)
+ [Configuration et utilisation des référentiels de packages](packages-repositories.md)
+ [Configuration et utilisation de référentiels en amont](packages-upstream-repositories.md)
+ [Connexion à des référentiels externes publics](packages-connect-external.md)
+ [Publication et modification de packages](working-with-packages.md)
+ [Utilisation de npm](packages-npm.md)
+ [Utilisation de Maven](packages-maven.md)
+ [En utilisant NuGet](packages-nuget.md)
+ [Utilisation de Python](packages-python.md)
+ [Quotas pour les packages](packages-quotas.md)
# Concepts de package
Voici quelques concepts et termes à connaître lors de la gestion, de la publication ou de la consommation de packages dans CodeCatalyst.
## Forfaits
Un *package* est un ensemble qui inclut à la fois le logiciel et les métadonnées nécessaires à l'installation du logiciel et à la résolution des dépendances. CodeCatalyst prend en charge le format de package npm.
Un package comprend :
+ Un nom (par exemple, `webpack` c'est le nom d'un package npm populaire)
+ Un espace de [noms](#packages-concepts-package-namespaces) facultatif (par exemple, `@types` dans`@types/node`)
+ Un ensemble de [versions](#packages-concepts-package-versions) (par exemple,`1.0.0`,`1.0.1`,`1.0.2`)
+ Métadonnées au niveau du package (par exemple, balises npm dist)
## Espaces de noms de packages
Certains formats de package prennent en charge les noms de packages hiérarchiques afin d'organiser les packages en groupes logiques et d'éviter les collisions de noms. Les packages portant le même nom peuvent être stockés dans différents espaces de noms. Par exemple, npm prend en charge les étendues, et le package npm `@types/node` a une portée `@types` et un nom de. `node` Il existe de nombreux autres noms de packages dans le `@types` champ d'application. Dans CodeCatalyst, la portée (« types ») est appelée espace de noms du package, et le nom (« nœud ») est appelé nom du package. Pour les packages Maven, l'espace de noms du package correspond au Maven GroupID. Le package Maven `org.apache.logging.log4j:log4j` possède un groupID (espace de noms de package) `org.apache.logging.log4j` et un artifactID (nom du package). `log4j` Certains formats de package tels que Python ne prennent pas en charge les noms hiérarchiques avec un concept similaire à npm scope ou Maven GroupID. Si vous n'avez aucun moyen de regrouper les noms de packages, il peut être plus difficile d'éviter les collisions de noms.
## Versions de package
Une *version de package* identifie la version spécifique d'un package, telle que`@types/node@12.6.9`. Le format et la sémantique du numéro de version varient en fonction des différents formats de package. Par exemple, les versions du package npm doivent être conformes à la spécification de [version sémantique](https://semver.org/). Dans CodeCatalyst, une version de package comprend l'identifiant de version, package-version-level les métadonnées et un ensemble de ressources.
## Assets
Un *actif* est un fichier individuel stocké dans CodeCatalyst lequel est associé à une version de package, tel qu'un fichier npm ou un `.tgz` fichier Maven POM ou JAR.
## Référentiels de packages
Un *référentiel de CodeCatalyst packages* contient un ensemble de [packages](#packages-concepts-packages), qui contiennent des [versions](#packages-concepts-package-versions) de packages, chacune correspondant à un ensemble de [ressources](#packages-concepts-assets). Les référentiels de packages sont polyglottes, ce qui signifie qu'un seul référentiel peut contenir tous les types de packages pris en charge. Chaque référentiel de packages expose des points de terminaison permettant de récupérer et de publier des packages à l'aide d'outils tels que NuGet CLIs (`nuget`,`dotnet`), la `npm` CLI, la CLI Maven (`mvn`) et Python CLIs (et). `pip` `twine` Pour plus d'informations sur les quotas de packages dans CodeCatalyst, notamment le nombre de référentiels de packages pouvant être créés dans chaque espace, consultez[Quotas pour les packages](packages-quotas.md).
Vous pouvez lier un dépôt de packages à un autre en le définissant comme un dépôt amont. Lorsqu'un dépôt est défini comme un dépôt amont, vous pouvez utiliser n'importe quel package en amont ainsi que tous les référentiels en amont supplémentaires de la chaîne. Pour de plus amples informations, veuillez consulter [Référentiels en amont](#packages-concepts-upstream-repositories).
Les référentiels Gateway sont un type spécial de référentiel de packages qui extrait et stocke les packages provenant d'autorités de packages externes officielles. Pour de plus amples informations, veuillez consulter [Référentiels de passerelle](#packages-concepts-gateway-repositories).
## Référentiels en amont
Vous pouvez l'utiliser CodeCatalyst pour créer une relation en amont entre deux référentiels de packages. Un référentiel de packages est *situé en amont* d'un autre lorsque les versions de packages qu'il contient sont accessibles depuis le point de terminaison du référentiel de packages du référentiel en aval. Dans le cadre d'une relation en amont, le contenu des deux référentiels de packages est efficacement fusionné du point de vue du client.
Par exemple, si un gestionnaire de packages demande une version de package qui n'existe pas dans un référentiel, il CodeCatalyst recherchera alors la version du package dans les référentiels en amont configurés. Les référentiels en amont sont recherchés dans l'ordre dans lequel ils sont configurés et, une fois qu'un package est trouvé, la recherche CodeCatalyst s'arrête.
## Référentiels de passerelle
Un *dépôt de passerelle* est un type spécial de dépôt de packages connecté à une autorité de package externe officielle prise en charge. Lorsque vous ajoutez un référentiel de passerelle [en tant que référentiel en amont](#packages-concepts-upstream-repositories), vous pouvez consommer des packages provenant de l'autorité officielle des packages correspondante. Votre référentiel en aval ne communique pas avec le référentiel public. Au contraire, tout est intermédiaire par le référentiel de passerelle. Les packages consommés de cette manière sont stockés à la fois dans le référentiel de passerelle et dans le référentiel en aval qui a reçu la demande initiale.
Les référentiels Gateway sont prédéfinis, mais ils doivent être créés dans chaque projet pour être utilisés. La liste suivante contient tous les référentiels de passerelle qui peuvent être créés CodeCatalyst et l'autorité de package à laquelle ils sont connectés.
+ **npm-public-registry-gateway**fournit des packages npm de npmjs.com.
+ **maven-central-gateway**fournit des packages Maven à partir du référentiel Maven Central.
+ **google-android-gateway**fournit des packages Maven à partir de Google Android.
+ **commonsware-gateway** fournit des packages Maven à partir de. CommonsWare
+ **gradle-plugins-gateway**fournit des packages Maven à partir de Gradle Plugins.
+ **nuget-gallery-gateway**fournit des NuGet packages provenant de la NuGet galerie.
+ **pypi-gateway fournit des** packages Python à partir de l'index des packages Python.
# Configuration et utilisation des référentiels de packages
Dans CodeCatalyst, les packages sont stockés et gérés dans des référentiels de packages. Pour publier des packages CodeCatalyst ou pour consommer des packages à partir d'un CodeCatalyst (ou de tout référentiel de packages public pris en charge), vous devez créer un référentiel de packages et y connecter votre gestionnaire de packages.
**Topics**
+ [Création d'un référentiel de packages](packages-repositories-create.md)
+ [Connexion à un référentiel de package](packages-repositories-connect.md)
+ [Supprimer un dépôt de packages](packages-repositories-delete.md)
# Création d'un référentiel de packages
Procédez comme suit pour créer un référentiel de packages dans CodeCatalyst.
**Pour créer un référentiel de packages**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Accédez au projet dans lequel vous souhaitez créer un référentiel de packages.
1. Dans le volet de navigation, sélectionnez **Packages**.
1. Sur la page **Référentiels de packages**, choisissez **Créer un référentiel de packages**.
1. Dans la section **Détails du référentiel du package**, ajoutez ce qui suit :
1. **Nom du référentiel**. Envisagez d'utiliser un nom descriptif avec des détails tels que le nom de votre projet ou de votre équipe, ou la manière dont le référentiel sera utilisé.
1. **Description** (Facultatif). La description d'un référentiel est particulièrement utile lorsque vous disposez de plusieurs référentiels répartis dans plusieurs équipes d'un projet.
1. Dans la section **Référentiels en amont**, choisissez **Sélectionner les référentiels en amont** pour ajouter les référentiels de packages auxquels vous souhaitez accéder via votre CodeCatalyst référentiel de packages. **Vous pouvez ajouter des **référentiels Gateway pour vous connecter à des référentiels** de packages externes ou à d'autres CodeCatalyst référentiels.**
1. Lorsqu'un package est demandé à partir d'un référentiel de packages, les référentiels en amont sont recherchés dans l'ordre dans lequel ils apparaissent dans cette liste. Une fois qu'un package est trouvé, la recherche CodeCatalyst s'arrête. Pour modifier l'ordre des référentiels en amont, vous pouvez glisser-déposer les référentiels dans la liste.
1. Choisissez **Create** pour créer votre référentiel de packages.
# Connexion à un référentiel de package
Pour publier ou utiliser des packages depuis CodeCatalyst, vous devez configurer votre gestionnaire de packages avec les informations et les informations d' CodeCatalyst identification du point de terminaison de votre référentiel de packages. Si vous n'avez pas créé de référentiel, vous pouvez le faire en suivant les instructions figurant dans[Création d'un référentiel de packages](packages-repositories-create.md).
Pour obtenir des instructions sur la façon de connecter un gestionnaire de CodeCatalyst packages à un référentiel de packages, consultez la documentation suivante.
+ [Configuration et utilisation de Gradle Groovy](packages-maven-gradle.md)
+ [Configuration et utilisation de mvn](packages-maven-mvn.md)
+ [Configuration et utilisation de la CLI nuget ou dotnet](packages-nuget-cli.md)
+ [Configuration et utilisation de npm](packages-npm-use.md)
+ [Configuration de pip et installation de packages Python](packages-python-pip.md)
+ [Configuration de Twine et publication de packages Python](packages-python-twine.md)
# Supprimer un dépôt de packages
Procédez comme suit pour supprimer un référentiel de packages dans CodeCatalyst.
**Pour supprimer un dépôt de packages**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Accédez au projet qui contient le référentiel de packages que vous souhaitez supprimer.
1. Dans le volet de navigation, sélectionnez **Packages**.
1. Sur la page **Référentiels de packages**, choisissez le référentiel que vous souhaitez supprimer.
1. Sélectionnez **Delete (Supprimer)**.
1. Consultez les informations fournies concernant les effets de la suppression d'un dépôt de packages.
1. Entrez `delete` dans le champ de saisie et choisissez **Supprimer**.
# Configuration et utilisation de référentiels en amont
Vous pouvez connecter à la fois des référentiels de passerelle et d'autres référentiels de CodeCatalyst packages en amont de vos référentiels de packages. Cela permet à un client du gestionnaire de packages d'accéder aux packages contenus dans plusieurs référentiels de packages en utilisant un seul point de terminaison de référentiel de packages. Les principaux avantages de l'utilisation de référentiels en amont sont les suivants :
+ Il vous suffit de configurer votre gestionnaire de packages avec un seul point de terminaison de référentiel à extraire de plusieurs sources.
+ Les packages consommés à partir d'un référentiel en amont sont stockés dans votre référentiel en aval, ce qui garantit la disponibilité de vos packages même si le référentiel en amont connaît des pannes inattendues ou si les packages du référentiel en amont sont supprimés.
Vous pouvez ajouter des référentiels en amont lorsque vous créez un référentiel de packages. Vous pouvez également ajouter ou supprimer des référentiels en amont des référentiels de packages existants dans la CodeCatalyst console.
Lorsque vous ajoutez un référentiel de passerelle en tant que référentiel en amont, le référentiel de packages est connecté au référentiel de packages public correspondant du référentiel de passerelle. Pour obtenir la liste des référentiels de packages publics pris en charge, consultez[Référentiels de packages externes pris en charge et leurs référentiels de passerelle](packages-connect-external.md#packages-upstream-repositories-supported-external).
Vous pouvez lier plusieurs référentiels ensemble en tant que référentiels en amont. Par exemple, supposons que votre équipe crée un référentiel nommé `project-repo` et utilise déjà un autre référentiel nommé `team-repo` qui a été **npm-public-registry-gateway**ajouté en tant que référentiel en amont, qui est connecté au référentiel public npm,`npmjs.com`. Vous pouvez l'ajouter en `team-repo` tant que référentiel en amont à`project-repo`. Dans ce cas, il vous suffit de configurer votre gestionnaire de packages pour l'utiliser `project-repo` pour extraire des packages depuis `project-repo``team-repo`,`npm-public-registry-gateway`, et`npmjs.com`.
**Topics**
+ [Ajout d’un référentiel en amont](packages-upstream-repositories-add.md)
+ [Modification de l'ordre de recherche des référentiels en amont](packages-upstream-repositories-search-order.md)
+ [Demande d'une version de package avec des référentiels en amont](packages-upstream-repositories-request.md)
+ [Suppression d'un référentiel en amont](packages-upstream-repositories-remove.md)
# Ajout d’un référentiel en amont
L'ajout d'un référentiel de packages public ou d'un autre CodeCatalyst référentiel de packages en tant que référentiel en amont à votre référentiel en aval met tous les packages du référentiel en amont à la disposition des gestionnaires de packages connectés au référentiel en aval.
**Pour ajouter un référentiel en amont**
1. Dans le panneau de navigation, choisissez **Packages**.
1. Sur la page **Référentiels de packages**, choisissez le référentiel de packages auquel vous souhaitez ajouter un référentiel en amont.
1. Sous le nom du référentiel de packages, choisissez **Upstreams**, **puis sélectionnez Select Upstream repositories**.
1. Dans **Sélectionner le type en amont**, choisissez l'une des options suivantes :
+ **Référentiels Gateway**
Vous pouvez choisir parmi la liste des référentiels de passerelle disponibles.
**Note**
Pour vous connecter aux autorités publiques chargées des packages externes, telles que Maven Central, npmjs.com ou Nuget Gallery, CodeCatalyst utilisez des référentiels de passerelle comme référentiels intermédiaires qui recherchent et stockent des packages extraits de référentiels externes. Cela permet d'économiser du temps et de transférer des données, car tous les référentiels de packages d'un projet utiliseront des packages provenant du référentiel intermédiaire de la passerelle. Pour de plus amples informations, veuillez consulter [Connexion à des référentiels externes publics](packages-connect-external.md).
+ **CodeCatalyst référentiels**
Vous pouvez choisir parmi la liste des référentiels de CodeCatalyst packages disponibles dans votre projet.
1. **Lorsque vous avez sélectionné tous les référentiels que vous souhaitez ajouter en tant que référentiels en amont, choisissez **Sélectionner**, puis Enregistrer.**
Pour plus d'informations sur la modification de l'ordre de recherche des référentiels en amont, consultez[Modification de l'ordre de recherche des référentiels en amont](packages-upstream-repositories-search-order.md).
Lorsque vous avez ajouté un dépôt en amont, vous pouvez utiliser un gestionnaire de packages connecté à votre dépôt local pour récupérer les packages depuis le dépôt en amont. Il n'est pas nécessaire de mettre à jour la configuration de votre gestionnaire de packages. Pour plus d'informations sur la demande de versions de package à partir d'un référentiel en amont, consultez[Demande d'une version de package avec des référentiels en amont](packages-upstream-repositories-request.md).
# Modification de l'ordre de recherche des référentiels en amont
CodeCatalyst recherche les référentiels en amont dans leur ordre de recherche configuré. Lorsqu'un package est trouvé, la recherche CodeCatalyst s'arrête. Vous pouvez modifier l'ordre dans lequel les packages sont recherchés dans les référentiels en amont.
**Pour modifier l'ordre de recherche des référentiels en amont**
1. Dans le panneau de navigation, choisissez **Packages**.
1. Sur la page **Référentiels de packages**, choisissez le référentiel de packages dont vous souhaitez modifier l'ordre de recherche en amont.
1. Sous le nom du référentiel de packages, choisissez **Upstreams**.
1. Dans la section **Référentiels en amont**, vous pouvez consulter les référentiels en amont et leur ordre de recherche. Pour modifier l'ordre de recherche, faites glisser les référentiels dans la liste.
1. Lorsque vous avez terminé de modifier l'ordre de recherche des référentiels en amont, choisissez **Enregistrer**.
# Demande d'une version de package avec des référentiels en amont
L'exemple suivant montre les scénarios possibles lorsqu'un gestionnaire de packages demande un package à partir d'un référentiel de CodeCatalyst packages contenant des référentiels en amont.
Dans cet exemple, un gestionnaire de packages, tel que`npm`, demande une version de package à partir d'un référentiel de packages nommé `downstream` qui possède plusieurs référentiels en amont. Lorsque le package est demandé, les événements suivants peuvent se produire :
+ S'il `downstream` contient la version du package demandée, il est renvoyé au client.
+ S'il `downstream` ne contient pas la version du package demandée, CodeCatalyst recherchez-la dans `downstream` les référentiels en amont, dans l'ordre de recherche configuré. Si la version du package est trouvée, une référence à celle-ci est `downstream` copiée et la version du package est renvoyée au client.
+ Si aucun `downstream` des référentiels en amont ne contient la version du package, une `Not Found` réponse HTTP 404 est renvoyée au client.
Le nombre maximum de référentiels en amont autorisés pour un référentiel est de 10. Le nombre maximum de CodeCatalyst recherches dans les référentiels 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 qui l'a demandée. Cela garantit que vous avez accès à vos packages en cas de panne inattendue du référentiel en amont. La version du package conservée n'est affectée par aucun des éléments suivants :
+ Suppression du référentiel en amont.
+ Déconnexion du référentiel en amont du référentiel en aval.
+ Suppression de la version du package du référentiel en amont.
+ Modification de la version du package dans le référentiel en amont (par exemple, en y ajoutant une nouvelle ressource).
## Récupération de packages via une relation en amont
CodeCatalyst peut récupérer des packages via plusieurs référentiels liés appelés référentiels en amont. Si un référentiel de CodeCatalyst packages possède une connexion en amont à un autre référentiel de CodeCatalyst packages doté d'une connexion en amont à un référentiel de passerelle, 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 une connexion en amont avec le référentiel de passerelle,`npm-public-registry-gateway`. `npm-public-registry-gateway`dispose d'une connexion en amont vers le référentiel public de packages, [https://npmjs.com](https://npmjs.com).
![\[Schéma de référentiel simple en amont montrant trois référentiels enchaînés.\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/packages/upstream-with-external.png)
S'il `npm` est configuré pour utiliser le `repo-A` référentiel, l'exécution `npm install` initie la copie des packages depuis et [https://npmjs.com](https://npmjs.com)vers`npm-public-registry-gateway`. Les versions installées sont également intégrées`repo-A`. L'exemple suivant permet d'installer. `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
```
Après l'exécution`npm install`, ne `repo-A` contient que la dernière version (`lodash 4.17.20`) car c'est la version qui a été récupérée par`npm`. `repo-A`
Étant donné qu'il `npm-public-registry-gateway` dispose d'une connexion externe en amont à [https://npmjs.com](https://npmjs.com), toutes les versions de package importées [https://npmjs.com](https://npmjs.com)sont stockées dans`npm-public-registry-gateway`. Ces versions de package auraient pu être récupérées par n'importe quel dépôt en aval disposant d'une connexion en amont menant à`npm-public-registry-gateway`.
Le contenu de `npm-public-registry-gateway` vous permet de voir tous les packages et versions de packages importés [https://npmjs.com](https://npmjs.com)au fil du temps.
## Rétention des packages dans des référentiels intermédiaires
CodeCatalyst vous permet d'enchaîner les référentiels en amont. Par exemple, il `repo-A` peut être `repo-B` utilisé comme référentiel en amont `repo-B` ou en `repo-C` tant que référentiel en amont. Cette configuration permet aux versions du package d'être intégrées `repo-B` et `repo-C` disponibles auprès de`repo-A`.
![\[Schéma de référentiel simple en amont montrant trois référentiels enchaînés.\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/packages/upstream-chaining.png)
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érentiel`repo-C`, la version du package n'est pas conservée dans le référentiel`repo-B`. La version du package n'est conservée que dans le référentiel le plus en aval, c'est-à-dire dans cet exemple. `repo-A` Il n'est conservé dans aucun référentiel intermédiaire. Cela est également vrai pour les chaînes plus longues ; par exemple, s'il y avait quatre référentiels :`repo-A`, `repo-B``repo-C`, et`repo-D`, et `repo-A` qu'un gestionnaire de packages était connecté pour `repo-A` récupérer une version de package`repo-D`, la version du package serait conservée dans ou pas dans `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 de packages public, sauf que la version du package est toujours conservée dans le référentiel de passerelle qui dispose d'une connexion directe en amont avec le référentiel public. Par exemple, `repo-A` a `repo-B` comme référentiel en amont. `repo-B`dispose `npm-public-registry-gateway` d'un dépôt en amont, qui dispose d'une connexion en amont au dépôt public, **npmjs.com** ; voir le schéma ci-dessous.
![\[Schéma du référentiel en amont montrant trois référentiels enchaînés avec une connexion amont externe à npmjs.com.\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/packages/upstream-chaining-external.png)
**Si un gestionnaire de packages connecté à `repo-A` demande une version de package spécifique, *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é `repo-A` car il s'agit du dépôt le plus en aval et `npm-public-registry-gateway` puisqu'il dispose d'une connexion en amont au référentiel externe public, npmjs.com.** *lodash 4.17.20* n'est pas conservé `repo-B` car il s'agit d'un dépôt intermédiaire.
# Suppression d'un référentiel en amont
Si vous ne souhaitez plus accéder aux packages d'un référentiel en amont, vous pouvez supprimer le référentiel en amont d'un référentiel de packages.
**Avertissement**
Lorsque vous supprimez un référentiel en amont, vous risquez de rompre les chaînes de relations en amont, ce qui pourrait interrompre vos projets ou vos builds.
**Pour supprimer un référentiel en amont**
1. Dans le panneau de navigation, choisissez **Packages**.
1. Sur la page **Référentiels de packages**, choisissez le référentiel de packages dont vous souhaitez supprimer un référentiel en amont.
1. Sous le nom du référentiel de packages, choisissez **Upstreams**.
1. Dans la section **Modifier les référentiels en amont**, recherchez le référentiel en amont que vous souhaitez supprimer et ![\[Remove\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/packages/remove.png) choisissez-le.
1. Lorsque vous avez terminé de supprimer les référentiels en amont, choisissez **Enregistrer**.
# Connexion à des référentiels externes publics
Vous pouvez connecter les référentiels de CodeCatalyst packages aux référentiels publics externes pris en charge en ajoutant le référentiel de passerelle correspondant en tant que référentiel en amont. Les référentiels Gateway agissent comme des référentiels intermédiaires qui recherchent et stockent des packages extraits de référentiels externes. Cela permet d'économiser du temps et de transférer des données, car tous les référentiels de packages d'un projet peuvent utiliser des packages stockés depuis le référentiel de passerelle.
**Pour vous connecter à un référentiel public à l'aide de référentiels de passerelle**
1. Dans le panneau de navigation, choisissez **Packages**.
1. Dans **Packages**, choisissez la page **des référentiels Gateway**. Vous pouvez consulter la liste des référentiels de passerelle pris en charge ainsi que leurs descriptions.
1. Pour utiliser un référentiel de passerelle, vous devez d'abord le créer. Si le référentiel de passerelle a été créé, la date et l'heure de sa création sont affichées. Si ce n'est pas le cas, choisissez **Create** pour le créer.
1. Pour utiliser des packages provenant du référentiel de passerelle, vous devez définir une connexion en amont avec celui-ci à partir d'un CodeCatalyst référentiel. Choisissez **Dépôts de packages** et choisissez le référentiel de packages auquel vous souhaitez vous connecter.
1. Pour vous connecter au référentiel public, choisissez **Upstreams**, **puis sélectionnez Select Upstream repositories**.
1. Choisissez **les référentiels** de passerelle, sélectionnez le référentiel de passerelle qui correspond au référentiel public auquel vous souhaitez vous connecter en tant que référentiel en amont.
1. **Lorsque vous avez sélectionné tous les référentiels de passerelle que vous souhaitez ajouter en tant que référentiels en amont, choisissez Select.**
1. Lorsque vous avez terminé de commander des référentiels en amont, choisissez **Enregistrer**.
Pour plus d'informations sur les référentiels en amont, consultez[Configuration et utilisation de référentiels en amont](packages-upstream-repositories.md).
Lorsque vous avez ajouté un référentiel de passerelle en tant que référentiel en amont, vous pouvez utiliser un gestionnaire de packages connecté à votre référentiel local pour récupérer les packages depuis le référentiel de packages externe public qui lui correspond. Il n'est pas nécessaire de mettre à jour la configuration de votre gestionnaire de packages. Les packages consommés de cette manière sont stockés à la fois dans le référentiel de passerelle et dans votre référentiel de packages local. Pour plus d'informations sur la demande de versions de package à partir d'un référentiel en amont, consultez[Demande d'une version de package avec des référentiels en amont](packages-upstream-repositories-request.md).
## Référentiels de packages externes pris en charge et leurs référentiels de passerelle
CodeCatalyst prend en charge l'ajout d'une connexion en amont aux autorités de package officielles suivantes avec des référentiels de passerelle.
| Type de package de référentiel | Description | Nom du référentiel Gateway |
| --- | --- | --- |
| npm | registre public npm | npm-public-registry-gateway |
| Python | Index des packages Python | pypi-gateway |
| Maven | Maven Central | maven-central-gateway |
| Maven | Référentiel Google Android | google-android-gateway |
| Maven | CommonsWare | commonsware-gateway |
| Maven | Référentiel de plugins Gradle | gradle-plugins-gateway |
| NuGet | NuGet Galerie | nuget-gallery-gateway |
# Publication et modification de packages
Un *package* contient CodeCatalyst un ensemble de logiciels et les métadonnées nécessaires pour résoudre les dépendances et installer le logiciel. Pour obtenir la liste des formats de package pris en charge dans CodeCatalyst, voir[Publiez et partagez des progiciels dans CodeCatalyst](packages.md). Cette section fournit des informations sur la publication, l'affichage, la suppression de packages et la mise à jour du statut d'une version de package.
**Topics**
+ [Publication de packages dans un référentiel de CodeCatalyst packages](package-publishing.md)
+ [Afficher les détails de la version du package](working-with-packages-view.md)
+ [Supprimer une version de package](working-with-packages-delete.md)
+ [Mettre à jour le statut d'une version de package](working-with-packages-update-version-status.md)
+ [Modification des contrôles d'origine des packages](package-origin-controls.md)
# Publication de packages dans un référentiel de CodeCatalyst packages
Vous pouvez publier des versions de n'importe quel type de package pris en charge dans un référentiel de CodeCatalyst packages à l'aide des outils du gestionnaire de packages. Les étapes pour publier une version de package sont les suivantes :
**Pour publier une version de package dans un référentiel de CodeCatalyst packages**
1. Si ce n'est pas le cas, [créez un référentiel de packages](packages-repositories-create.md).
1. Connectez votre gestionnaire de packages à votre référentiel de packages. Pour obtenir des instructions sur la façon de connecter le gestionnaire de packages npm à un référentiel de CodeCatalyst packages, consultez[Configuration et utilisation de npm](packages-npm-use.md).
1. Utilisez votre gestionnaire de packages connecté pour publier les versions de vos packages.
**Contents**
+ [Publication et référentiels en amont](#package-publishing-upstreams)
+ [Packages privés et référentiels publics](#package-publishing-upstreams-direct)
+ [Remplacement des actifs du package](#package-publishing-overwrite-assets)
## Publication et référentiels en amont
Dans CodeCatalyst, vous ne pouvez pas publier les versions de package présentes dans des référentiels en amont ou des référentiels publics accessibles. Supposons, par exemple, que vous souhaitiez publier un package npm dans un référentiel de packages et `myrepo` que vous soyez `myrepo` connecté à npmjs.com via un référentiel de passerelle configuré en tant que référentiel en amont. `lodash@1.0` S'il `lodash@1.0` est présent dans le référentiel en amont ou dans npmjs.com, CodeCatalyst rejette toute tentative de publication dans ce référentiel en `myrepo` émettant une erreur de conflit 409. Cela vous permet d'éviter de publier accidentellement un package portant le même nom et la même version qu'un package dans un référentiel en amont, ce qui peut entraîner un comportement inattendu.
Vous pouvez toujours publier les différentes versions d'un nom de package qui existent dans un référentiel en amont. Par exemple, s'il `lodash@1.0` est présent dans un référentiel en amont, mais `lodash@1.1` qu'il ne l'est pas, vous pouvez `lodash@1.1` publier dans le référentiel en aval.
## Packages privés et référentiels publics
CodeCatalyst ne publie pas les packages stockés dans CodeCatalyst des référentiels publics, tels que npmjs.com ou Maven Central. CodeCatalyst importe des packages depuis des référentiels publics vers un CodeCatalyst référentiel, mais cela ne déplace pas les packages dans la direction opposée. Les packages que vous publiez dans CodeCatalyst des référentiels restent privés et ne sont disponibles que pour le CodeCatalyst projet auquel appartient le référentiel.
## 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 avec un actif `mypackage-1.0.jar` 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. 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 ressources (Python et Maven), vous pouvez à tout moment ajouter de nouvelles ressources portant des noms différents à une version de package existante, en supposant que vous disposez des autorisations requises. Étant donné que npm NuGet ne prend en charge qu'un seul actif par version de package, pour modifier une version de package publiée, vous devez d'abord la supprimer.
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.
# Afficher les détails de la version du package
Vous pouvez utiliser la CodeCatalyst console pour afficher les détails d'une version de package spécifique.
**Pour afficher les détails de la version du package**
1. Dans le panneau de navigation, choisissez **Packages**.
1. Sur la page **Référentiels de packages**, choisissez le référentiel contenant la version du package dont vous souhaitez afficher les détails.
1. Recherchez la version du package dans le tableau **Packages**. Vous pouvez utiliser la barre de recherche pour filtrer les packages par nom et format de package. Choisissez le package dans la liste.
1. Sur la page **Détails du package**, choisissez **Versions**, puis choisissez la version que vous souhaitez consulter.
# Supprimer une version de package
Vous pouvez supprimer une version du package depuis la page des **détails de la version du package** de la CodeCatalyst console.
**Pour supprimer une version de package**
1. Dans le panneau de navigation, choisissez **Packages**.
1. Sur la page **Référentiels de packages**, choisissez le référentiel contenant la version du package que vous souhaitez supprimer.
1. Recherchez et choisissez le package dans le tableau.
1. Sur la page **Détails du package**, choisissez **Versions** et choisissez la version que vous souhaitez supprimer.
1. Sur la page des **détails de la version du package**, sélectionnez **Actions de version**, puis sélectionnez **Supprimer**.
1. Entrez *Supprimer* dans le champ de texte et choisissez **Supprimer**.
# Mettre à jour le statut d'une version de package
Chaque version de package CodeCatalyst 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 la CodeCatalyst console. Pour plus d'informations sur les valeurs d'état possibles des versions de package et leur signification, consultez[État de la version du package](#package-version-status).
**Pour mettre à jour le statut d'une version de package**
1. Dans le panneau de navigation, choisissez **Packages**.
1. Sur la page **Référentiels de packages**, choisissez le référentiel contenant la version du package dont vous souhaitez mettre à jour le statut.
1. Recherchez et choisissez le package dans le tableau.
1. Sur la page **Détails du package**, choisissez **Versions**, puis choisissez la version que vous souhaitez consulter.
1. Sur la page des **détails de la version du package**, sélectionnez **Actions**, puis choisissez **Dérépertorier**, **Archiver** ou Supprimer**.** Pour plus d'informations sur le statut de chaque version de package, consultez[État de la version du package](#package-version-status).
1. Entrez le texte de confirmation dans le champ de texte, puis choisissez ****Dérépertorier****, **Archiver** ou Supprimer, selon le statut vers lequel vous souhaitez effectuer la mise à jour.
## État de la version du package
Les valeurs possibles pour l'état de la version du package sont les suivantes. Vous pouvez modifier le statut de la version du package dans la console. Pour de plus amples informations, veuillez consulter [Mettre à jour le statut d'une version de package](#working-with-packages-update-version-status).
+ **Publié** : La version du package a été publiée avec succès et peut être demandée par 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 de`npm view versions`. Toutes les ressources de la version du package sont disponibles dans le référentiel.
+ **Inachevée** : la dernière tentative de publication n’a pas été terminée. Actuellement, seules les versions du package Maven peuvent avoir le statut **Inachevé**. 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.
+ **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 versions`inclut pas la version du package. Cela signifie que la logique de résolution des dépendances npm ne sélectionne 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 l'exécution`npm ci`.
+ **Archivé** : Les ressources de la version du package ne peuvent pas ê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 le build de votre application dépend d'une version mise à jour vers **Archivé**, le build échouera, sauf si la version du package a é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 celle-ci est toujours présente dans le référentiel. Cependant, vous pouvez redéfinir le statut de la version du package sur **Non répertorié** ou **Publié** dans la console.
+ **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 sont définitivement supprimés par CodeCatalyst. 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 pas être utilisée car les actifs ont été supprimés. Lorsqu'une version du package est marquée comme **supprimée**, le stockage des actifs du package ne vous est pas facturé.
Outre les statuts de la liste précédente, une version de package peut également être supprimée. Après sa suppression, une version de package ne se trouve pas 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.
## Nom du package, version du package et normalisation du nom des actifs
CodeCatalyst 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 CodeCatalyst 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 CodeCatalyst pour chaque type de package, consultez la documentation suivante.
+ [Normalisation du nom des paquets Python](python-name-normalization.md)
+ [NuGet normalisation du nom du package, de la version et du nom des actifs](nuget-name-normalization.md)
CodeCatalyst n'effectue pas de normalisation sur les autres formats de package.
# Modification des contrôles d'origine des packages
Sur Amazon CodeCatalyst, les versions de packages peuvent être ajoutées à un référentiel de packages en les publiant directement, en les extrayant d'un référentiel en amont ou en les ingérant depuis un référentiel public externe via une passerelle. Si vous autorisez l'ajout de versions d'un package à la fois par publication directe et par ingestion à partir de référentiels publics, vous êtes vulnérable à une attaque de substitution de dépendance. Pour de plus amples informations, veuillez consulter [Attaques de substitution de la dépendance](#dependency-substitution-attacks). Pour vous protéger contre une attaque de substitution de dépendance, configurez les contrôles d'origine des packages sur un package dans un référentiel afin de limiter la manière dont les versions de ce package peuvent être ajoutées au référentiel.
Vous devriez envisager de configurer les contrôles d'origine des packages pour que les nouvelles versions des différents packages proviennent à la fois de sources internes, telles que la publication directe, et de sources externes, telles que des référentiels publics. Par défaut, les contrôles d'origine des packages sont configurés en fonction de la manière dont la première version d'un package est ajoutée au référentiel.
## Paramètres de contrôle de l'origine des packages
Grâce aux contrôles de l'origine des packages, vous pouvez configurer la manière dont les versions des packages peuvent être ajoutées à un référentiel. Les listes suivantes incluent les paramètres et valeurs de contrôle d'origine des packages disponibles.
**Publish**
Ce paramètre permet de configurer si les versions des packages peuvent être publiées directement dans le référentiel à l'aide de gestionnaires de packages ou d'outils similaires.
+ **AUTORISER** : les versions du package peuvent être publiées directement.
+ **BLOCK** : Les versions du package ne peuvent pas être publiées directement.
**En amont**
Ce paramètre définit si les versions des packages peuvent être ingérées à partir de référentiels publics externes ou conservées à partir de référentiels en amont à la demande d'un gestionnaire de packages.
+ **AUTORISER** : Toute version de package peut être conservée à partir d'autres CodeCatalyst référentiels configurés en tant que référentiels en amont ou ingérée à partir d'une source publique via une connexion externe.
+ **BLOCAGE** : Les versions de package ne peuvent pas être conservées à partir d'autres CodeCatalyst référentiels configurés comme référentiels en amont ou ingérées à partir d'une source publique avec une connexion externe.
### Paramètres de contrôle de l'origine des packages par défaut
Les contrôles d'origine des packages par défaut pour un package seront basés sur la manière dont la première version de ce package est ajoutée au référentiel de packages.
+ Si la première version du package est publiée directement par un gestionnaire de packages, les paramètres seront **Publish : ALLOW** et **Upstream : BLOCK.**
+ Si la première version du package est ingérée à partir d'une source publique, les paramètres seront **Publish : BLOCK** et **Upstream : ALLOW**.
## Scénarios courants de contrôle d'accès aux packages
Cette section décrit certains scénarios courants d'ajout d'une version de package à un référentiel de CodeCatalyst packages. Les paramètres de contrôle de l'origine des packages sont définis pour les nouveaux packages en fonction de la manière dont la première version du package est ajoutée.
Dans les scénarios suivants, un *package interne* est publié directement depuis un gestionnaire de packages vers votre référentiel, tel qu'un package que vous gérez. Un *package externe* est un package existant dans un dépôt public qui peut être ingéré dans votre référentiel via un référentiel passerelle en amont.
**Une version de package externe est publiée pour un package interne existant**
Dans ce scénario, considérez un package interne, *PackageA*. Votre équipe publie la première version du package pour *PackageA dans un* référentiel de CodeCatalyst packages. Comme il s'agit de la première version de package pour ce package, les paramètres de contrôle de l'origine du package sont automatiquement définis **sur Publier : Autoriser** et **Upstream : Bloquer**. Une fois le package publié dans votre référentiel, un package portant le même nom est publié dans un référentiel public connecté à votre référentiel de CodeCatalyst packages. Il peut s'agir d'une tentative d'attaque de substitution de dépendance contre le package interne ou d'une coïncidence. Quoi qu'il en soit, les contrôles d'origine des packages sont configurés pour bloquer l'ingestion de la nouvelle version externe afin de se protéger contre une attaque potentielle.
Dans l'image suivante, *RePoA* est votre référentiel de CodeCatalyst packages avec une connexion en amont avec le `npm-public-registry-gateway` référentiel. Votre dépôt contient les versions 1.1 et 2.1 de *PackageA*, mais la version 3.0 est publiée dans le dépôt public. Normalement, *RePoA* ingère la version 3.0 une fois que le package a été demandé par un gestionnaire de packages. L'ingestion de packages étant définie sur **Bloquer**, la version 3.0 n'est pas ingérée dans votre référentiel de CodeCatalyst packages et n'est pas disponible pour les gestionnaires de packages qui y sont connectés.
![\[Graphique simple illustrant le blocage d'une nouvelle version de package externe dans un dépôt public.\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/packages/package-origin-controls-one.png)
**Une version de package interne est publiée pour un package externe existant**
Dans ce scénario, un package, *PackageB*, existe en externe dans un référentiel public que vous avez connecté à votre référentiel. Lorsqu'un gestionnaire de packages connecté à votre référentiel demande *PackageB*, la version du package est ingérée dans votre référentiel depuis le référentiel public. Comme il s'agit de la première version de package de *PackageB* ajoutée à votre référentiel, les paramètres d'origine du package sont configurés sur **Publish : BLOCK et Upstream :** **ALLOW**. Plus tard, vous essayez de publier une version portant le même nom de package dans le référentiel. Vous ne connaissez peut-être pas le package public et vous essayez de publier un package indépendant portant le même nom, ou vous essayez peut-être de publier une version corrigée, ou vous essayez peut-être de publier directement la version exacte du package qui existe déjà en externe. CodeCatalyst rejette la version que vous essayez de publier, mais vous pouvez annuler explicitement le rejet et publier la version, si nécessaire.
Dans l'image suivante, *RePoA* est votre référentiel de CodeCatalyst packages avec une connexion en amont avec le `npm-public-registry-gateway` référentiel. Votre dépôt de packages contient la version 3.0 qu'il a ingérée depuis le dépôt public. Vous souhaitez publier la version 1.2 dans votre référentiel de packages. Généralement, vous pouvez publier la version 1.2 sur *RePoA*, mais comme la publication est définie sur **Bloquer**, la version 1.2 ne peut pas être publiée.
![\[Graphique simple montrant que la publication du package est bloquée.\]](http://docs.aws.amazon.com/fr_fr/codecatalyst/latest/userguide/images/packages/package-origin-controls-two.png)
**Publication d'une version de package corrigée d'un package externe existant**
Dans ce scénario, un package, *PackageB*, existe en externe dans un référentiel public que vous avez connecté à votre référentiel de packages. Lorsqu'un gestionnaire de packages connecté à votre référentiel demande *PackageB*, la version du package est ingérée dans votre référentiel depuis le référentiel public. Comme il s'agit de la première version de package de *PackageB* ajoutée à votre référentiel, les paramètres d'origine du package sont configurés sur **Publish : BLOCK et Upstream :** **ALLOW**. Votre équipe décide de publier les versions corrigées de ce package dans le référentiel. Pour pouvoir publier directement les versions des packages, votre équipe modifie les paramètres de contrôle de l'origine des packages en **Publish : ALLOW** et **Upstream : BLOCK**. Les versions de ce package peuvent désormais être publiées directement dans votre dépôt et ingérées à partir de référentiels publics. Une fois que votre équipe a publié les versions du package corrigées, elle rétablit les paramètres d'origine du package sur **Publish : BLOCK et Upstream :** **ALLOW**.
## Modification des contrôles d'origine des packages
Les contrôles d'origine des packages sont configurés automatiquement en fonction de la manière dont la première version d'un package est ajoutée au référentiel de packages. Pour de plus amples informations, veuillez consulter [Paramètres de contrôle de l'origine des packages par défaut](#default-package-origin-control-settings). Pour ajouter ou modifier des contrôles d'origine de package pour un package dans un référentiel de CodeCatalyst packages, effectuez les étapes de la procédure suivante.
**Pour ajouter ou modifier les contrôles d'origine des packages**
1. Dans le panneau de navigation, choisissez **Packages**.
1. Choisissez le référentiel de packages qui contient le package que vous souhaitez modifier.
1. Dans le tableau **Packages**, recherchez et choisissez le package que vous souhaitez modifier.
1. Sur la page récapitulative du package, choisissez **Origin controls**.
1. Dans **Contrôles d'origine**, choisissez les contrôles d'origine du package que vous souhaitez définir pour ce package. Les deux paramètres de contrôle de l'origine du package, **Publish** et **Upstream**, doivent être définis en même temps.
+ Pour autoriser la publication directe des versions du package, dans **Publier**, sélectionnez **Autoriser**. Pour bloquer la publication des versions du package, choisissez **Bloquer**.
+ **Pour autoriser l'ingestion de packages provenant de référentiels externes et l'extraction de packages depuis des référentiels en amont, dans **Sources en amont**, sélectionnez Autoriser.** Pour bloquer toute ingestion et extraction de versions de packages depuis des référentiels externes et en amont, choisissez **Bloquer.**
1. Choisissez **Enregistrer**.
## Publication et référentiels en amont
Dans CodeCatalyst, vous ne pouvez pas publier les versions de package présentes dans des référentiels en amont ou des référentiels publics accessibles. Par exemple, supposons que vous souhaitiez publier un package `lodash@1.0` npm dans un référentiel et `myrepo` que vous disposiez d'un référentiel en amont avec une connexion externe à npmjs.com. `myrepo` Envisagez les scénarios suivants.
1. Les paramètres de contrôle de l'origine du package `lodash` sont **Publish : ALLOW** et **Upstream : ALLOW**. S'il `lodash@1.0` est présent dans le référentiel en amont ou dans npmjs.com, CodeCatalyst rejette toute tentative de publication dans ce référentiel en `myrepo` émettant une erreur de conflit 409. Vous pouvez toujours publier une version différente, telle que`lodash@1.1`.
1. Les paramètres de contrôle de l'origine du package `lodash` sont **Publish : ALLOW** et **Upstream : BLOCK**. Vous pouvez publier n'importe quelle version `lodash` de dans votre référentiel qui n'existe pas encore car les versions des packages ne sont pas accessibles.
1. Les paramètres de contrôle de l'origine du package `lodash` sont **Publish : BLOCK** et **Upstream : ALLOW**. Vous ne pouvez publier aucune version de package directement dans votre référentiel.
## Attaques de substitution de la dépendance
Les gestionnaires de packages simplifient le processus d'empaquetage et de partage de code réutilisable. Ces packages peuvent être des packages privés développés par une organisation pour être utilisés dans ses applications, ou il peut s'agir de packages publics, généralement open source, développés en dehors d'une organisation et distribués par des référentiels de packages publics. Lorsqu'ils demandent des packages, les développeurs s'appuient sur leur gestionnaire de packages pour récupérer les nouvelles versions de leurs dépendances. Les attaques de substitution de dépendances, également appelées attaques de confusion des dépendances, exploitent le fait qu'un gestionnaire de packages n'a généralement aucun moyen de distinguer les versions légitimes d'un package des versions malveillantes.
Les attaques par substitution de dépendance appartiennent à un sous-ensemble d'attaques connues sous le nom d'attaques de la chaîne logistique logicielle. Une attaque de chaîne d'approvisionnement logicielle est une attaque qui tire parti de vulnérabilités situées à n'importe quel niveau de la chaîne d'approvisionnement logicielle.
Une attaque de substitution de dépendance peut cibler toute personne utilisant à la fois des packages développés en interne et des packages extraits de référentiels publics. Les attaquants identifient les noms de packages internes, puis placent stratégiquement le code malveillant portant le même nom dans des référentiels de packages publics. Généralement, le code malveillant est publié dans un package dont le numéro de version est élevé. Les gestionnaires de packages récupèrent le code malveillant à partir de ces flux publics car ils pensent que les packages malveillants sont les dernières versions du package. Cela provoque une « confusion » ou une « substitution » entre le package souhaité et le package malveillant, ce qui entraîne la compromission du code.
Pour empêcher les attaques de substitution de dépendance, Amazon CodeCatalyst fournit des contrôles de l'origine des colis. Les contrôles d'origine des packages sont des paramètres qui contrôlent la manière dont les packages peuvent être ajoutés à vos référentiels. Les contrôles sont configurés automatiquement lorsque la première version d'un nouveau package est ajoutée à un CodeCatalyst référentiel. Ils peuvent garantir que les versions des packages ne peuvent pas être publiées directement dans votre référentiel et ingérées à partir de sources publiques, ce qui vous protège des attaques de substitution de dépendances. Pour plus d'informations sur les contrôles d'origine des packages et sur la manière de les modifier, consultez[Modification des contrôles d'origine des packages](#package-origin-controls).
# Utilisation de npm
Ces rubriques décrivent comment vous pouvez utiliser `npm` le gestionnaire de packages Node.js avec CodeCatalyst.
**Note**
CodeCatalyst supports `node v4.9.1` et plus tard `npm v5.0.0` et plus tard.
**Topics**
+ [Configuration et utilisation de npm](packages-npm-use.md)
+ [gestion des balises npm](packages-npm-tags.md)
# Configuration et utilisation de npm
Pour l'utiliser `npm` avec CodeCatalyst, vous devez vous connecter `npm` à votre référentiel de packages et fournir un jeton d'accès personnel (PAT) pour l'authentification. Vous pouvez consulter les instructions de connexion `npm` à votre référentiel de packages dans la CodeCatalyst console.
**Contents**
+ [Configuration de npm avec CodeCatalyst](#npm-configure)
+ [Installation de packages npm à partir d'un référentiel CodeCatalyst de packages](#npm-install)
+ [Installation de packages npm depuis npmjs via CodeCatalyst](#npm-install-npmjs)
+ [Publication de packages npm dans votre référentiel de CodeCatalyst packages](#npm-publish)
+ [support des commandes npm](#npm-commands)
+ [Commandes prises en charge qui interagissent avec un référentiel de packages](#supported-commands-that-interact-with-a-repository)
+ [Commandes côté client prises en charge](#supported-client-side-commands)
+ [Commandes non prises en charge](#unsupported-commands)
## Configuration de npm avec CodeCatalyst
Les instructions suivantes expliquent comment vous authentifier et vous connecter `npm` à votre référentiel de CodeCatalyst packages. Pour plus d'informations sur npm, consultez la documentation [officielle de npm.](https://docs.npmjs.com/)
**Pour vous connecter `npm` à votre référentiel de CodeCatalyst packages**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Accédez à votre projet.
1. Dans le panneau de navigation, choisissez **Packages**.
1. Choisissez votre référentiel de packages dans la liste.
1. Choisissez **Connect to repository**.
1. Dans **Détails de configuration**, dans **Package manager client**, choisissez **npm client**.
1. Choisissez votre système d'exploitation pour afficher les étapes de configuration correspondantes.
1. Un jeton d'accès personnel (PAT) est requis pour authentifier npm avec. CodeCatalyst Si vous avez déjà un jeton, vous pouvez l'utiliser. Si ce n'est pas le cas, vous pouvez en créer un en suivant les étapes ci-dessous.
1. **(Facultatif) :** Mettez à jour le **nom PAT** et la **date d'expiration**.
1. Choisissez **Créer un jeton**.
1. Copiez et stockez votre PAT dans un endroit sûr.
**Avertissement**
Vous ne pourrez plus voir ou copier votre PAT une fois que vous aurez fermé la boîte de dialogue. Les informations d'identification doivent être de courte durée afin de minimiser le temps pendant lequel un attaquant peut les utiliser après les avoir détournées.
1. Exécutez les commandes suivantes depuis le répertoire racine de votre projet pour configurer npm avec votre référentiel de packages. Les commandes effectueront les opérations suivantes :
+ Créez un `.npmrc` fichier au niveau du projet si votre projet n'en possède pas.
+ Ajoutez les informations de point de terminaison du référentiel de packages à votre fichier au niveau du projet`.npmrc`.
+ Ajoutez vos informations d'identification (PAT) à votre `.npmrc` fichier de niveau utilisateur.
Remplacez les valeurs suivantes.
**Note**
Si vous copiez les instructions de la console, les valeurs des commandes suivantes sont mises à jour pour vous et il n'est pas nécessaire de les modifier.
+ Remplacez *username* par votre nom CodeCatalyst d'utilisateur.
+ *PAT*Remplacez-le par votre CodeCatalyst PAT.
+ *space\$1name*Remplacez-le par le nom de votre CodeCatalyst espace.
+ Remplacez *proj\$1name* par le nom CodeCatalyst de votre projet.
+ *repo\$1name*Remplacez-le par le nom CodeCatalyst du dépôt de votre package.
```
npm set registry=https://packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/ --location project
npm set //packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/:_authToken=username:PAT
```
**Pour npm 6 ou inférieur :** pour que npm transmette toujours le jeton d'authentification à CodeCatalyst, même pour les `GET` demandes, définissez la variable de configuration always-auth comme suit. `npm config set`
```
npm set //packages.region.codecatalyst.aws/npm/space-name/proj-name/repo-name/:always-auth=true --location project
```
## Installation de packages npm à partir d'un référentiel CodeCatalyst de packages
Après avoir connecté npm à votre référentiel en suivant les étapes décrites dans[Configuration de npm avec CodeCatalyst](#npm-configure), vous pouvez exécuter des `npm` commandes sur votre référentiel.
Vous pouvez installer un package npm qui se trouve dans votre référentiel de CodeCatalyst packages ou dans l'un de ses référentiels en amont à l'aide de la `npm install` commande.
```
npm install lodash
```
## Installation de packages npm depuis npmjs via CodeCatalyst
Vous pouvez installer des packages npm depuis [npmjs.com](https://www.npmjs.com/) via un CodeCatalyst référentiel en configurant le référentiel avec une connexion en amont au référentiel de passerelle connecté à npmjs.com,. **npm-public-registry-gateway** Les packages installés à partir de npmjs sont ingérés et stockés dans le référentiel de passerelle, le référentiel de packages le plus éloigné en aval.
**Pour installer des packages depuis npmjs**
1. Si ce n'est pas déjà fait, configurez `npm` avec votre référentiel de CodeCatalyst packages en suivant les étapes décrites dans[Configuration de npm avec CodeCatalyst](#npm-configure).
1. Vérifiez que votre référentiel a ajouté le référentiel de passerelle **npm-public-registry-gateway**, en tant que connexion en amont. Vous pouvez vérifier quelles sources en amont sont ajoutées ou ajoutées en **npm-public-registry-gateway**tant que source en amont en suivant les instructions [Ajout d’un référentiel en amont](packages-upstream-repositories-add.md) et en choisissant le **npm-public-registry-gateway**référentiel.
1. Installez les packages à l'aide de la `npm install` commande.
```
npm install package_name
```
Pour plus d'informations sur la demande de packages à partir de référentiels en amont, consultez[Demande d'une version de package avec des référentiels en amont](packages-upstream-repositories-request.md).
## Publication de packages npm dans votre référentiel de CodeCatalyst packages
Une fois que vous avez terminé[Configuration de npm avec CodeCatalyst](#npm-configure), vous pouvez exécuter `npm` des commandes.
Vous pouvez publier un package npm dans un référentiel de CodeCatalyst packages à l'aide de la `npm publish` commande.
```
npm publish
```
Pour plus d'informations sur la création de packages npm, voir [Création de modules Node.js](https://docs.npmjs.com/getting-started/creating-node-modules) sur *npm Docs*.
## support des commandes npm
Les sections suivantes résument les `npm` commandes prises en charge par les référentiels de CodeCatalyst packages, en plus de répertorier les commandes spécifiques qui ne sont pas prises en charge.
**Topics**
+ [Commandes prises en charge qui interagissent avec un référentiel de packages](#supported-commands-that-interact-with-a-repository)
+ [Commandes côté client prises en charge](#supported-client-side-commands)
+ [Commandes non prises en charge](#unsupported-commands)
### Commandes prises en charge qui interagissent avec un référentiel de packages
Cette section répertorie `npm` les commandes dans lesquelles le `npm` client envoie une ou plusieurs requêtes au registre pour lequel il est configuré (par exemple,`npm config set registry`). Il a été vérifié que ces commandes fonctionnent correctement lorsqu'elles sont invoquées dans un référentiel de CodeCatalyst packages.
****
| Commande | Description |
| --- | --- |
| [punaises](https://docs.npmjs.com/cli/bugs) | Devine l'emplacement de l'URL de suivi des bogues d'un package, puis tente de l'ouvrir. |
| [ci](https://docs.npmjs.com/cli/ci) | Installe un projet sur une table rase. |
| [déprécier](https://docs.npmjs.com/cli/deprecate) | Déprécie une version d'un package. |
| [dist-tag](https://docs.npmjs.com/cli/dist-tag) | Modifie les balises de distribution des packages. |
| [documents](https://docs.npmjs.com/cli/docs) | Devine l'emplacement de l'URL de documentation d'un package, puis tente de l'ouvrir à l'aide du paramètre de `--browser` configuration. |
| [médecin](https://docs.npmjs.com/cli/doctor) | Exécute un ensemble de vérifications pour valider que votre installation npm peut gérer vos JavaScript packages. |
| [installer](https://docs.npmjs.com/cli/install) | Installe un package. |
| [install-ci-test](https://docs.npmjs.com/cli/install-ci-test) | Installe un projet sur une table rase et exécute des tests. Pseudonyme :`npm cit`. Cette commande exécute un`npm ci`, suivi immédiatement d'un`npm test`. |
| [installation-test](https://docs.npmjs.com/cli/install-test) | Installe le package et exécute des tests. Exécute un`npm install`, suivi immédiatement d'un`npm test`. |
| [désuet](https://docs.npmjs.com/cli/outdated) | Vérifie le registre configuré pour déterminer si les packages installés sont obsolètes. |
| [ping](https://docs.npmjs.com/cli/ping) | Envoie une requête ping au registre npm configuré ou donné et vérifie l'authentification. |
| [publier](https://docs.npmjs.com/cli/publish) | Publie une version du package dans le registre. |
| [update](https://docs.npmjs.com/cli/update) | Devine l'emplacement de l'URL du dépôt d'un package, puis tente de l'ouvrir à l'aide du paramètre de `--browser` configuration. |
| [vue](https://docs.npmjs.com/cli/view) | Affiche les métadonnées du package. Peut également être utilisé pour imprimer les propriétés des métadonnées. |
### Commandes côté client prises en charge
Ces commandes ne nécessitent aucune interaction directe avec un dépôt de packages et CodeCatalyst ne nécessitent donc rien pour les prendre en charge.
****
| Commande | Description |
| --- | --- |
| [poubelle (héritage)](https://docs.npmjs.com/cli/v8/commands/npm-bin) | Affiche le `bin` répertoire npm. |
| [build](https://docs.npmjs.com/cli/v6/commands/npm-build) | Construit un package. |
| [cache](https://docs.npmjs.com/cli/cache) | Manipule le cache des packages. |
| [achèvement](https://docs.npmjs.com/cli/completion) | Permet de compléter les onglets dans toutes les commandes npm. |
| [configuration](https://docs.npmjs.com/cli/config) | Met à jour le contenu des `npmrc` fichiers utilisateur et globaux. |
| [dédupliquez](https://docs.npmjs.com/cli/dedupe) | Effectue une recherche dans l'arborescence des packages locaux et tente de simplifier la structure en déplaçant les dépendances plus haut dans l'arborescence, où elles peuvent être partagées plus efficacement par plusieurs packages dépendants. |
| [modifier](https://docs.npmjs.com/cli/edit) | Modifie un package installé. Sélectionne une dépendance dans le répertoire de travail actuel et ouvre le répertoire du package dans l'éditeur par défaut. |
| [explorez](https://docs.npmjs.com/cli/explore) | Parcourt un package installé. Génère un sous-shell dans le répertoire du package installé spécifié. Si une commande est spécifiée, elle est exécutée dans le sous-shell, qui s'arrête alors immédiatement. |
| [help](https://docs.npmjs.com/cli/help) | Obtient de l'aide sur npm. |
| [aide-recherche](https://docs.npmjs.com/cli/help-search) | Recherche la documentation d'aide de npm. |
| [initialisation](https://docs.npmjs.com/cli/init) | Crée un `package.json` fichier. |
| [lien](https://docs.npmjs.com/cli/link) | Établit des liens symboliques vers un répertoire de packages. |
| [ls](https://docs.npmjs.com/cli/ls) | Répertorie les packages installés. |
| [pack](https://docs.npmjs.com/cli/pack) | Crée une archive tar à partir d'un package. |
| [prefix](https://docs.npmjs.com/cli/prefix) | Affiche un préfixe. Il s'agit du répertoire parent le plus proche à contenir un `package.json` fichier, sauf indication contraire`-g`. |
| [pruneau](https://docs.npmjs.com/cli/prune) | Supprime les packages qui ne figurent pas dans la liste des dépendances du package parent. |
| [reconstruire](https://docs.npmjs.com/cli/rebuild) | Exécute la `npm build` commande sur les dossiers correspondants. |
| [redémarrer](https://docs.npmjs.com/cli/restart) | Exécute les scripts d'arrêt, de redémarrage et de démarrage d'un package ainsi que les pré-scripts et post-scripts associés. |
| [racine](https://docs.npmjs.com/cli/root) | Imprime le `node_modules` répertoire effectif en sortie standard. |
| [exécuter un script](https://docs.npmjs.com/cli/run-script) | Exécute des scripts de package arbitraires. |
| [shrinkwrap](https://docs.npmjs.com/cli/shrinkwrap) | Verrouille les versions de dépendance pour publication. |
| [désinstaller](https://docs.npmjs.com/cli/uninstall) | Désinstalle un package. |
### Commandes non prises en charge
Ces `npm` commandes ne sont pas prises en charge par les référentiels de CodeCatalyst packages.
****
| Commande | Description | Remarques |
| --- | --- | --- |
| [accès](https://docs.npmjs.com/cli/access) | Définit le niveau d'accès aux packages publiés. | CodeCatalyst utilise un modèle d'autorisation différent de celui du référentiel public npmjs. |
| [ajouter un utilisateur](https://docs.npmjs.com/cli/adduser) | Ajoute un compte utilisateur au registre | CodeCatalyst utilise un modèle utilisateur différent du référentiel public npmjs. |
| [audit](https://docs.npmjs.com/cli/audit) | Exécute un audit de sécurité. | CodeCatalyst ne vend actuellement pas de données relatives aux failles de sécurité. |
| [crochet](https://docs.npmjs.com/cli/v9/commands/npm-hook) | Gère les hooks npm, y compris l'ajout, la suppression, la liste et la mise à jour. | CodeCatalyst ne prend actuellement en charge aucun mécanisme de notification des modifications. |
| [login](https://docs.npmjs.com/cli-commands/adduser.html) | Authentifie un utilisateur. Ceci est un alias pour `npm adduser`. | CodeCatalyst utilise un modèle d'authentification différent de celui du dépôt public npmjs. Pour plus d'informations, consultez [Configuration de npm avec CodeCatalyst](#npm-configure). |
| [logout](https://docs.npmjs.com/cli/logout) | Se déconnecte du registre. | CodeCatalyst utilise un modèle d'authentification différent de celui du dépôt public npmjs. Il n'est pas possible de se déconnecter d'un CodeCatalyst référentiel, mais les jetons d'authentification expirent après leur date d'expiration configurable. La durée du jeton par défaut est de 12 heures. |
| [propriétaire](https://docs.npmjs.com/cli/owner) | Gère les propriétaires de packages. | CodeCatalyst utilise un modèle d'autorisations différent de celui du référentiel public npmjs. |
| [profile](https://docs.npmjs.com/cli/profile) | Modifie les paramètres de votre profil de registre. | CodeCatalyst utilise un modèle utilisateur différent du référentiel public npmjs. |
| [search](https://docs.npmjs.com/cli/search) | Recherche dans le registre les packages correspondant aux termes de recherche. | CodeCatalyst ne prend pas en charge la `search` commande. |
| [étoile](https://docs.npmjs.com/cli/star) | Marque vos packages préférés. | CodeCatalyst ne prend actuellement en charge aucun mécanisme de favoris. |
| [étoiles](https://docs.npmjs.com/cli/stars) | Affiche les packages marqués comme favoris. | CodeCatalyst ne prend actuellement en charge aucun mécanisme de favoris. |
| [équipe](https://docs.npmjs.com/cli/team) | Gère les équipes et les adhésions aux équipes. | CodeCatalyst utilise un modèle d'adhésion d'utilisateurs et de groupes différent de celui du référentiel public npmjs. |
| [https://docs.npmjs.com/cli/token](https://docs.npmjs.com/cli/token)token | Gère vos jetons d'authentification. | CodeCatalyst utilise un modèle différent pour obtenir des jetons d'authentification. Pour plus d'informations, consultez [Configuration de npm avec CodeCatalyst](#npm-configure). |
| [dépublier](https://docs.npmjs.com/cli/unpublish) | Supprime un package du registre. | CodeCatalyst ne prend pas en charge la suppression d'une version de package d'un référentiel à l'aide du client npm. Vous pouvez supprimer un package dans la console. |
| [whoami](https://docs.npmjs.com/cli/whoami) | Affiche le nom d'utilisateur npm. | CodeCatalyst utilise un modèle utilisateur différent du référentiel public npmjs. |
# gestion des balises npm
Les registres npm prennent en charge les *balises*, qui sont des alias de chaîne pour les versions de packages. Vous pouvez utiliser des balises pour fournir un alias au lieu d'utiliser des numéros de version. Par exemple, vous avez un projet comportant plusieurs flux de développement et vous utilisez une balise différente pour chaque flux (par exemple`stable`,`beta`,`dev`,`canary`). Pour plus d'informations, consultez [dist-tag](https://docs.npmjs.com/cli/dist-tag) sur *npm* Docs.
Par défaut, npm utilise la `latest` balise pour identifier la version actuelle d'un package. `npm install pkg`(sans `@version` ou `@tag` spécificateur) installe la dernière balise. Généralement, les projets n'utilisent la balise la plus récente que pour les versions stables. D'autres balises sont utilisées pour les versions instables ou préliminaires.
## Modification des balises avec le client npm
Les trois `npm dist-tag` commandes (`add`,`rm`, et`ls`) fonctionnent de la même manière dans les référentiels de CodeCatalyst packages que dans le registre [npm par défaut](https://registry.npmjs.com/).
## balises npm et référentiels en amont
Lorsque `npm` les balises d'un package et les versions de ce package sont également présentes dans un référentiel en amont, CodeCatalyst fusionne les balises avant de les renvoyer au client. Par exemple, un référentiel nommé `R` possède un référentiel en amont nommé`U`. Le tableau suivant indique les balises d'un package nommé `web-helper` présent dans les deux référentiels.
****
| Référentiel | Nom du package | Étiquettes du package |
| --- | --- | --- |
| R | `web-helper` | *dernier* (alias pour la version 1.0.0) |
| U | `web-helper` | *alpha* (alias pour la version 1.0.1) |
Dans ce cas, lorsque le client npm récupère les balises du `web-helper` package depuis le référentiel`R`, il reçoit à la fois les balises les *plus récentes* et les balises *alpha*. Les versions vers lesquelles pointent les balises ne changeront pas.
Lorsque la même balise est présente sur le même package à la fois dans le référentiel en amont et dans le référentiel local, CodeCatalyst utilise la balise qui a été *mise à jour pour la dernière fois*. Supposons, par exemple, que les balises de *webhelper* aient été modifiées pour ressembler à ce qui suit.
****
| Référentiel | Nom du package | Étiquettes du package | Dernière mise à jour |
| --- | --- | --- | --- |
| R | `web-helper` | *dernier* (alias pour la version 1.0.0) | 1er janvier 2023 |
| U | `web-helper` | *dernier* (alias pour la version 1.0.1) | 1er juin 2023 |
Dans ce cas, lorsque le client npm récupère les balises du package *web-helper* depuis le référentiel`R`, la *dernière* balise alias la version *1.0.1* car elle a été mise à jour pour la dernière fois. Cela permet de consommer facilement de nouvelles versions de package dans un référentiel en amont qui ne sont pas encore présentes dans un référentiel local en exécutant`npm update`.
# Utilisation de Maven
Le format de référentiel Maven est utilisé par de nombreux langages, notamment Java, Kotlin, Scala et Clojure. Il est pris en charge par de nombreux outils de construction différents, notamment Maven, Gradle, Scala SBT, Apache Ivy et Leiningen.
Nous avons testé et confirmé la compatibilité avec CodeCatalyst les versions suivantes :
+ Dernière version **de Maven** : 3.6.3.
+ Dernière version de **Gradle** : 6.4.1. La version 5.5.1 a également été testée.
**Topics**
+ [Configuration et utilisation de Gradle Groovy](packages-maven-gradle.md)
+ [Configuration et utilisation de mvn](packages-maven-mvn.md)
+ [Publication de packages avec curl](packages-maven-curl.md)
+ [Utilisation des checksums et des instantanés Maven](packages-maven-checksums-snapshots.md)
# Configuration et utilisation de Gradle Groovy
Pour utiliser Gradle Groovy avec CodeCatalyst, vous devez connecter Gradle Groovy à votre référentiel de packages et fournir un jeton d'accès personnel (PAT) pour l'authentification. Vous pouvez consulter les instructions pour connecter Gradle Groovy à votre référentiel de packages dans la console. CodeCatalyst
**Contents**
+ [Récupération des dépendances depuis CodeCatalyst](#gradle-fetch-dependencies)
+ [Récupération de plugins depuis CodeCatalyst](#gradle-fetch-plugins)
+ [Récupération de packages depuis des référentiels de packages externes via CodeCatalyst](#gradle-install-public)
+ [Publier des packages vers CodeCatalyst](#gradle-publish-packages)
+ [Exécution d'une version Gradle dans IntelliJ IDEA](#gradle-intellij)
+ [Méthode 1 : insérez le PAT `gradle.properties`](#gradle-intellij-gradle-properties)
+ [Méthode 2 : Placer le PAT dans un fichier séparé](#gradle-intellij-file)
## Récupération des dépendances depuis CodeCatalyst
Les instructions suivantes expliquent comment configurer Gradle Groovy pour récupérer les dépendances de votre référentiel de packages. CodeCatalyst
**Pour utiliser Gradle Groovy pour récupérer les dépendances de votre référentiel de packages CodeCatalyst**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Accédez à votre projet.
1. Dans le panneau de navigation, choisissez **Packages**.
1. Choisissez votre référentiel de packages dans la liste des référentiels de packages.
1. Choisissez **Connect to repository**.
1. Dans la boîte de dialogue **Connect to repository**, choisissez **Gradle Groovy** dans la liste des clients du gestionnaire de packages.
1. Vous aurez besoin d'un jeton d'accès personnel (PAT) pour authentifier Gradle Groovy. CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Si ce n'est pas le cas, vous pouvez en créer un ici.
1. Choisissez **Créer un jeton**.
1. Choisissez **Copier** pour copier votre PAT.
**Avertissement**
Vous ne pourrez plus voir ou copier votre PAT après avoir fermé la boîte de dialogue.
1. Mettez à jour votre fichier de propriétés Gradle avec vos identifiants d'accès. *username*Remplacez-le par votre CodeCatalyst nom d'utilisateur et *PAT* remplacez-le par votre jeton d'accès CodeCatalyst personnel. Vous pouvez utiliser n'importe quelle valeur pour *spaceUsername* et à *spacePassword* condition d'utiliser les mêmes valeurs dans les étapes suivantes.
```
spaceUsername=username
spacePassword=PAT
```
1. Pour récupérer les dépendances CodeCatalyst dans une version Gradle, copiez l'extrait de `maven` code et ajoutez-le à la `repositories` section du fichier de votre projet. `build.gradle` Remplacez les valeurs suivantes. Vous pouvez utiliser n'importe quelle valeur *spaceName* tant que vous utilisez les mêmes valeurs dans les étapes suivantes.
**Note**
Si vous copiez les instructions depuis la console, les valeurs suivantes doivent être mises à jour pour vous et ne doivent pas être modifiées.
+ Remplacez *space\$1name* par le nom de votre CodeCatalyst espace.
+ Remplacez *proj\$1name* par le nom CodeCatalyst de votre projet.
+ *repo\$1name*Remplacez-le par le nom CodeCatalyst du dépôt de votre package.
```
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
```
1. (Facultatif) Pour utiliser le référentiel de CodeCatalyst packages comme seule source pour les dépendances de votre projet, supprimez du `build.gradle` fichier toutes les autres sections des référentiels. Si vous avez plusieurs référentiels, Gradle recherche les dépendances dans chaque référentiel dans l'ordre dans lequel elles sont répertoriées.
## Récupération de plugins depuis CodeCatalyst
Par défaut, Gradle résoudra les plugins à partir du portail public des [plugins Gradle](https://plugins.gradle.org/). Les étapes suivantes configurent votre projet Gradle pour résoudre les plugins à partir de votre référentiel de CodeCatalyst packages.
**Pour utiliser Gradle pour récupérer des plugins depuis votre référentiel de packages CodeCatalyst**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Accédez à votre projet.
1. Dans le panneau de navigation, choisissez **Packages**.
1. Choisissez votre référentiel de packages dans la liste des référentiels de packages.
1. Choisissez **Connect to repository**.
1. Dans la boîte de dialogue **Connect to repository**, choisissez **Gradle** dans la liste des clients du gestionnaire de packages.
1. Vous aurez besoin d'un jeton d'accès personnel (PAT) pour authentifier Gradle. CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Si ce n'est pas le cas, vous pouvez en créer un ici.
1. Choisissez **Créer un jeton**.
1. Choisissez **Copier** pour copier votre PAT.
**Avertissement**
Vous ne pourrez plus voir ou copier votre PAT après avoir fermé la boîte de dialogue.
1. Mettez à jour votre fichier de propriétés Gradle avec vos identifiants d'accès. *username*Remplacez-le par votre CodeCatalyst nom d'utilisateur et *PAT* remplacez-le par votre jeton d'accès CodeCatalyst personnel. Vous pouvez utiliser n'importe quelle valeur pour *spaceUsername* et à *spacePassword* condition d'utiliser les mêmes valeurs dans les étapes suivantes.
```
spaceUsername=username
spacePassword=PAT
```
1. Ajoutez un `pluginManagement` bloc à votre `settings.gradle` fichier. Le `pluginManagement` bloc doit apparaître avant toute autre instruction dans`settings.gradle`. Remplacez les valeurs suivantes.
**Note**
Si vous copiez les instructions depuis la console, les valeurs suivantes doivent être mises à jour pour vous et ne doivent pas être modifiées.
+ Remplacez *spaceName* par la valeur du nom utilisée à l'étape précédente.
+ Remplacez *space\$1name* par le nom de votre CodeCatalyst espace.
+ Remplacez *proj\$1name* par le nom CodeCatalyst de votre projet.
+ *repo\$1name*Remplacez-le par le nom CodeCatalyst du dépôt de votre package.
```
pluginManagement {
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
}
```
Cela garantira que Gradle résout les plugins à partir du référentiel spécifié. Le référentiel doit avoir une connexion en amont configurée avec le portail des plugins Gradle (`gradle-plugins-store`) afin que les plugins Gradle couramment requis soient disponibles pour la compilation. Pour plus d'informations, consultez la [documentation Gradle](https://docs.gradle.org/current/userguide/plugins.html#sec:custom_plugin_repositories).
## Récupération de packages depuis des référentiels de packages externes via CodeCatalyst
Vous pouvez installer des packages Maven à partir de référentiels publics via un CodeCatalyst référentiel en le configurant avec une connexion en amont à la passerelle qui représente le référentiel de passerelle. Les packages installés depuis le référentiel de passerelle sont ingérés et stockés dans votre CodeCatalyst référentiel.
CodeCatalyst prend en charge les référentiels publics de packages Maven suivants.
+ maven-central-gateway
+ google-android-gateway
+ gradle-plugins-gateway
+ passerelle commonware
**Pour installer des packages à partir de référentiels de packages Maven publics**
1. Si ce n'est pas déjà fait, configurez Gradle avec votre référentiel de CodeCatalyst packages en suivant les étapes décrites dans [Récupération des dépendances depuis CodeCatalyst](#gradle-fetch-dependencies) ou[Récupération de plugins depuis CodeCatalyst](#gradle-fetch-plugins).
1. Assurez-vous que votre référentiel a ajouté le référentiel de passerelle à partir duquel vous souhaitez effectuer l'installation en tant que connexion en amont. Vous pouvez le faire en suivant les instructions fournies [Ajout d’un référentiel en amont](packages-upstream-repositories-add.md) et en choisissant le référentiel public de packages que vous souhaitez ajouter en amont.
Pour plus d'informations sur la demande de packages à partir de référentiels en amont, consultez[Demande d'une version de package avec des référentiels en amont](packages-upstream-repositories-request.md).
## Publier des packages vers CodeCatalyst
Cette section décrit comment publier une bibliothèque Java créée avec Gradle Groovy dans un référentiel. CodeCatalyst
**Pour utiliser Gradle Groovy pour publier des packages dans un référentiel de packages CodeCatalyst**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Sur la page d'aperçu de votre projet, sélectionnez **Packages**.
1. Choisissez votre référentiel de packages dans la liste des référentiels de packages.
1. Choisissez **Connect to repository**.
1. Dans la boîte de dialogue **Connect to repository**, choisissez **Gradle Groovy** dans la liste des clients du gestionnaire de packages.
1. Vous aurez besoin d'un jeton d'accès personnel (PAT) pour authentifier Gradle. CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Si ce n'est pas le cas, vous pouvez en créer un ici.
1. Choisissez **Créer un jeton**.
1. Choisissez **Copier** pour copier votre PAT.
**Avertissement**
Vous ne pourrez plus voir ou copier votre PAT après avoir fermé la boîte de dialogue.
1. Mettez à jour votre fichier de propriétés Gradle avec vos identifiants d'accès. *username*Remplacez-le par votre CodeCatalyst nom d'utilisateur et *PAT* remplacez-le par votre jeton d'accès CodeCatalyst personnel. Vous pouvez utiliser n'importe quelle valeur pour *spaceUsername* et à *spacePassword* condition d'utiliser les mêmes valeurs dans les étapes suivantes.
```
spaceUsername=username
spacePassword=PAT
```
1. Ajoutez le `maven-publish` plugin à la `plugins` section du `build.gradle` fichier du projet.
```
plugins {
id 'java-library'
id 'maven-publish'
}
```
1. Ajoutez ensuite une `publishing` section au `build.gradle` fichier de projet. Remplacez les valeurs suivantes.
**Note**
Si vous copiez les instructions depuis la console, les valeurs suivantes doivent être mises à jour pour vous et ne doivent pas être modifiées.
+ Remplacez *space\$1name* par le nom de votre CodeCatalyst espace.
+ Remplacez *proj\$1name* par le nom CodeCatalyst de votre projet.
+ *repo\$1name*Remplacez-le par le nom CodeCatalyst du dépôt de votre package.
```
publishing {
publications {
mavenJava(MavenPublication) {
groupId = 'group-id'
artifactId = 'artifact-id'
version = 'version'
from components.java
}
}
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
}
```
Le `maven-publish` plugin génère un fichier POM basé sur le `groupId``artifactId`, et `version` spécifié dans la `publishing` section.
1. Une fois ces modifications `build.gradle` terminées, exécutez la commande suivante pour créer le projet et le télécharger dans le référentiel.
```
./gradlew publish
```
1. Accédez à votre référentiel de packages dans la CodeCatalyst console pour vérifier que le package a bien été publié. Vous devriez voir le package dans la liste des **packages** de votre référentiel de packages.
Pour plus d'informations, consultez les rubriques suivantes sur le site Web de Gradle :
+ [Création de bibliothèques Java](https://guides.gradle.org/building-java-libraries/)
+ [Publier un projet sous forme de module](https://docs.gradle.org/current/userguide/publishing_setup.html)
## Exécution d'une version Gradle dans IntelliJ IDEA
Vous pouvez exécuter une version Gradle dans IntelliJ IDEA qui extrait les dépendances de. CodeCatalyst Pour authentifier Gradle auprès de Gradle CodeCatalyst, vous devez utiliser un jeton d'accès personnel (PAT). Vous pouvez enregistrer votre CodeCatalyst PAT dans `gradle.properties` ou dans un fichier séparé de votre choix.
### Méthode 1 : insérez le PAT `gradle.properties`
Utilisez cette méthode si vous n'utilisez pas le `gradle.properties` fichier et que vous pouvez remplacer son contenu par votre PAT. Si vous l'utilisez`gradle.properties`, vous pouvez modifier cette méthode pour ajouter le PAT au lieu de remplacer le contenu du fichier.
**Note**
L'exemple montre le `gradle.properties` fichier situé dans`GRADLE_USER_HOME`.
Créez d'abord un PAT si vous n'en avez pas.
**Pour créer un jeton d'accès personnel (PAT)**
1. Dans la barre de menu supérieure, choisissez votre badge de profil, puis sélectionnez **Mes paramètres**.
**Astuce**
Vous pouvez également accéder à votre profil utilisateur en vous rendant sur la page des membres d'un projet ou d'un espace et en choisissant votre nom dans la liste des membres.
1. Dans **Nom du PAT**, entrez un nom descriptif pour votre PAT.
1. Dans **Date d'expiration**, laissez la date par défaut ou cliquez sur l'icône du calendrier pour sélectionner une date personnalisée. La date d'expiration par défaut est d'un an à compter de la date actuelle.
1. Choisissez **Créer**.
Vous pouvez également créer ce jeton lorsque vous choisissez **Clone un référentiel** pour un référentiel source.
1. Enregistrez le secret PAT dans un emplacement sécurisé.
**Important**
Le secret PAT ne s'affiche qu'une seule fois. Vous ne pouvez pas le récupérer après avoir fermé la fenêtre.
Ensuite, mettez à jour votre `build.gradle` fichier avec l'extrait suivant :
```
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
```
### Méthode 2 : Placer le PAT dans un fichier séparé
Utilisez cette méthode si vous ne souhaitez pas modifier votre `gradle.properties` fichier.
Créez d'abord un PAT si vous n'en avez pas.
**Pour créer un jeton d'accès personnel (PAT)**
1. Dans la barre de menu supérieure, choisissez votre badge de profil, puis sélectionnez **Mes paramètres**.
**Astuce**
Vous pouvez également accéder à votre profil utilisateur en vous rendant sur la page des membres d'un projet ou d'un espace et en choisissant votre nom dans la liste des membres.
1. Dans **Nom du PAT**, entrez un nom descriptif pour votre PAT.
1. Dans **Date d'expiration**, laissez la date par défaut ou cliquez sur l'icône du calendrier pour sélectionner une date personnalisée. La date d'expiration par défaut est d'un an à compter de la date actuelle.
1. Choisissez **Créer**.
Vous pouvez également créer ce jeton lorsque vous choisissez **Clone un référentiel** pour un référentiel source.
1. Enregistrez le secret PAT dans un emplacement sécurisé.
**Important**
Le secret PAT ne s'affiche qu'une seule fois. Vous ne pouvez pas le récupérer après avoir fermé la fenêtre.
**Pour placer votre PAT dans un fichier séparé**
1. Mettez à jour votre `build.gradle` fichier avec l'extrait suivant. Remplacez *space\$1name**proj\$1name*, et *repo\$1name* par votre nom CodeCatalyst d'utilisateur, le nom de l'espace, le nom du projet et le nom du référentiel de packages.
```
def props = new Properties()
file("fileName").withInputStream { props.load(it) }
repositories {
maven {
name = 'spaceName'
url = uri('https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/')
credentials(PasswordCredentials)
}
}
}
```
1. Écrivez votre PAT dans le fichier indiqué dans votre `build.gradle` fichier :
```
echo "codecatalystArtifactsToken=PAT" > fileName
```
# Configuration et utilisation de mvn
Vous utilisez la `mvn` commande pour exécuter les versions de Maven. Vous devez configurer `mvn` pour utiliser votre référentiel de packages et fournir un jeton d'accès personnel (PAT) pour l'authentification.
**Contents**
+ [Récupération des dépendances depuis CodeCatalyst](#mvn-fetch-dependencies)
+ [Récupération de packages depuis des référentiels de packages externes via CodeCatalyst](#mvn-install-public)
+ [Publier des packages vers CodeCatalyst](#mvn-publish-packages)
+ [Publication de packages tiers](#publishing-third-party-packages)
## Récupération des dépendances depuis CodeCatalyst
Pour configurer `mvn` afin d'extraire les dépendances d'un CodeCatalyst référentiel, vous devez modifier le fichier de configuration Maven `settings.xml` et, éventuellement, le fichier POM (Project Model Object) de votre projet. Le fichier POM contient des informations sur le projet et des informations de configuration permettant à Maven de créer le projet, telles que les dépendances, le répertoire de construction, le répertoire des sources, le répertoire des sources de test, le plugin et les objectifs.
**À utiliser `mvn` pour récupérer les dépendances depuis votre dépôt de CodeCatalyst packages**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Sur la page d'aperçu de votre projet, sélectionnez **Packages**.
1. Choisissez votre référentiel de packages dans la liste des référentiels de packages.
1. Choisissez **Connect to repository**.
1. Dans la boîte de dialogue **Connect to repository**, choisissez **mvn dans** la liste des clients du gestionnaire de packages.
1. Vous aurez besoin d'un jeton d'accès personnel (PAT) pour vous authentifier. `mvn` CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Sinon, vous pouvez en créer un ici.
1. Choisissez **Créer un jeton**.
1. Choisissez **Copier** pour copier votre PAT.
**Avertissement**
Vous ne pourrez plus voir ou copier votre PAT après avoir fermé la boîte de dialogue.
1. Ajoutez à votre fichier un profil contenant votre `settings.xml` dépôt. Remplacez les valeurs suivantes.
**Note**
Si vous copiez les instructions depuis la console, les valeurs suivantes doivent être mises à jour pour vous et ne doivent pas être modifiées.
+ Remplacez *space\$1name* par le nom de votre CodeCatalyst espace.
+ Remplacez *proj\$1name* par le nom CodeCatalyst de votre projet.
+ *repo\$1name*Remplacez-le par le nom CodeCatalyst du dépôt de votre package.
```
repo_name
true
repo_name
https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/
```
1. Ajoutez votre serveur à la liste des serveurs de votre `settings.xml` fichier. Remplacez les valeurs suivantes.
**Note**
Si vous copiez les instructions depuis la console, les valeurs suivantes doivent être mises à jour pour vous et ne doivent pas être modifiées.
+ *repo\$1name*Remplacez-le par le nom CodeCatalyst du dépôt de votre package.
+ Remplacez *username* par votre nom CodeCatalyst d'utilisateur.
+ *PAT*Remplacez-le par votre CodeCatalyst PAT.
```
repo_name
username
PAT
```
1. (Facultatif) Définissez un miroir dans votre `settings.xml` fichier qui capture toutes les connexions et les achemine vers votre référentiel au lieu d'un référentiel de passerelle.
**Note**
Si vous copiez les instructions depuis la console, les valeurs suivantes doivent être mises à jour pour vous et ne doivent pas être modifiées.
+ Remplacez *space\$1name* par le nom de votre CodeCatalyst espace.
+ Remplacez *proj\$1name* par le nom CodeCatalyst de votre projet.
+ *repo\$1name*Remplacez-le par le nom CodeCatalyst du dépôt de votre package.
```
repo_name
repo_name
https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/
*
```
**Important**
Vous pouvez utiliser n'importe quelle valeur dans l'``élément, mais elle doit être identique dans les `` éléments `` et. Cela permet d'inclure les informations d'identification spécifiées dans les demandes adressées à CodeCatalyst.
Après avoir apporté ces modifications de configuration, vous pouvez créer le projet.
```
mvn compile
```
## Récupération de packages depuis des référentiels de packages externes via CodeCatalyst
Vous pouvez installer des packages Maven à partir de référentiels publics via un CodeCatalyst référentiel en le configurant avec une connexion en amont à la passerelle qui représente le référentiel de passerelle. Les packages installés à partir du référentiel de passerelle sont ingérés et stockés dans votre CodeCatalyst référentiel.
Actuellement, CodeCatalyst prend en charge les référentiels de packages Maven publics suivants.
+ maven-central-gateway
+ google-android-gateway
+ gradle-plugins-gateway
+ passerelle commonware
**Pour installer des packages à partir de référentiels de packages Maven publics**
1. Si ce n'est pas déjà fait, configurez `mvn` avec votre référentiel de CodeCatalyst packages en suivant les étapes décrites dans[Récupération des dépendances depuis CodeCatalyst](#mvn-fetch-dependencies).
1. Assurez-vous que votre référentiel a ajouté le référentiel de passerelle à partir duquel vous souhaitez effectuer l'installation en tant que connexion en amont. Pour vérifier quelles sources en amont sont ajoutées ou pour ajouter un référentiel de passerelle en tant que source en amont, suivez les instructions figurant dans[Ajout d’un référentiel en amont](packages-upstream-repositories-add.md).
Pour plus d'informations sur la demande de packages à partir de référentiels en amont, consultez[Demande d'une version de package avec des référentiels en amont](packages-upstream-repositories-request.md).
## Publier des packages vers CodeCatalyst
Pour publier un package Maven dans un CodeCatalyst dépôt, vous devez également modifier `~/.m2/settings.xml` le POM du projet. `mvn`
**À utiliser `mvn` pour publier des packages dans votre référentiel de CodeCatalyst packages**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Sur la page d'aperçu de votre projet, sélectionnez **Packages**.
1. Choisissez votre référentiel de packages dans la liste des référentiels de packages.
1. Choisissez **Connect to repository**.
1. Dans la boîte de dialogue **Connect to repository**, choisissez **mvn dans** la liste des clients du gestionnaire de packages.
1. Vous aurez besoin d'un jeton d'accès personnel (PAT) pour vous authentifier. `mvn` CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Sinon, vous pouvez en créer un ici.
1. Choisissez **Créer un jeton**.
1. Choisissez **Copier** pour copier votre PAT.
**Avertissement**
Vous ne pourrez plus voir ou copier votre PAT après avoir fermé la boîte de dialogue.
1. Configurez une variable d'environnement sur votre machine locale avec votre PAT. Vous allez utiliser cette variable d'environnement dans votre `setting.xml` fichier.
```
export CODECATALYST_ARTIFACTS_TOKEN=your_PAT
```
1. Ajoutez une `` section à `settings.xml` avec une référence à la variable d'`CodeCatalyst_ARTIFACTS_TOKEN`environnement afin que Maven transmette le jeton dans les requêtes HTTP.
```
...
repo-name
username
${env.CodeCatalyst_ARTIFACTS_TOKEN}
...
```
1. Ajoutez une `` section à celle de votre projet`pom.xml`.
```
...
repo_name
repo_name
https://packages.region.codecatalyst.aws/maven/space_name/proj_name/repo_name/
...
```
Après avoir apporté ces modifications de configuration, vous pouvez créer le projet et le publier dans le référentiel spécifié.
```
mvn deploy
```
Vous pouvez accéder à votre référentiel de packages dans la CodeCatalyst console pour vérifier que le package a bien été publié.
## Publication de packages tiers
Vous pouvez publier des packages Maven tiers dans un CodeCatalyst référentiel avec`mvn deploy:deploy-file`. Cela peut être utile aux utilisateurs qui souhaitent publier des packages qui ne disposent que de fichiers JAR et qui n'ont pas accès au code source du package ou aux fichiers POM.
La `mvn deploy:deploy-file` commande générera un fichier POM basé sur les informations transmises dans la ligne de commande.
Créez d'abord un PAT si vous n'en avez pas.
**Pour créer un jeton d'accès personnel (PAT)**
1. Dans la barre de menu supérieure, choisissez votre badge de profil, puis sélectionnez **Mes paramètres**.
**Astuce**
Vous pouvez également accéder à votre profil utilisateur en vous rendant sur la page des membres d'un projet ou d'un espace et en choisissant votre nom dans la liste des membres.
1. Dans **Nom du PAT**, entrez un nom descriptif pour votre PAT.
1. Dans **Date d'expiration**, laissez la date par défaut ou cliquez sur l'icône du calendrier pour sélectionner une date personnalisée. La date d'expiration par défaut est d'un an à compter de la date actuelle.
1. Choisissez **Créer**.
Vous pouvez également créer ce jeton lorsque vous choisissez **Clone un référentiel** pour un référentiel source.
1. Enregistrez le secret PAT dans un emplacement sécurisé.
**Important**
Le secret PAT ne s'affiche qu'une seule fois. Vous ne pouvez pas le récupérer après avoir fermé la fenêtre.
**Pour publier des packages Maven tiers**
1. Créez un `~/.m2/settings.xml` fichier avec le contenu suivant :
```
repo_name
username
PAT}
```
1. Exécutez la commande `mvn deploy:deploy-file` :
```
mvn deploy:deploy-file -DgroupId=commons-cli \
-DartifactId=commons-cli \
-Dversion=1.4 \
-Dfile=./commons-cli-1.4.jar \
-Dpackaging=jar \
-DrepositoryId=repo-name \
-Durl=https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/
```
**Note**
L'exemple précédent publie`commons-cli 1.4`. Modifiez les arguments groupId, artifactID, version et fichier pour publier un JAR différent.
Ces instructions sont basées sur des exemples du [Guide de déploiement d'un tiers JARs sur un dépôt distant](https://maven.apache.org/guides/mini/guide-3rd-party-jars-remote.html), extrait de la *documentation d'Apache Maven*.
Pour plus d'informations, consultez les rubriques suivantes sur le site Web du projet Apache Maven :
+ [Configuration de plusieurs référentiels](https://maven.apache.org/guides/mini/guide-multiple-repositories.html)
+ [Référence des paramètres](https://maven.apache.org/settings.html)
+ [Gestion de la distribution](https://maven.apache.org/pom.html#Distribution_Management)
+ [Profilés](https://maven.apache.org/pom.html#Profiles)
# Publication de packages avec curl
Cette section explique comment utiliser le client HTTP `curl` pour publier des packages Maven dans un CodeCatalyst référentiel de packages. La publication de packages avec `curl` peut être utile si vous ne possédez pas ou ne souhaitez pas installer le client Maven dans vos environnements.
**Pour publier un package Maven avec `curl`**
1. Vous devez stocker un jeton d'accès personnel (PAT) dans une variable d'environnement pour vous authentifier. `curl` CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Sinon, vous pouvez en créer une et configurer la variable d'environnement.
1. Créez un PAT en suivant les étapes décrites dans[Accorder aux utilisateurs l'accès au référentiel avec des jetons d'accès personnels](ipa-tokens-keys.md). Copiez le PAT pour le stocker dans une variable d'environnement.
1. Sur la ligne de commande de votre machine locale, configurez une variable d'environnement avec votre PAT.
```
export CodeCatalyst_ARTIFACTS_TOKEN=your_PAT
```
1. Utilisez la `curl` commande suivante pour publier le fichier JAR dans un CodeCatalyst référentiel. Remplacez*username*, *space\$1name**proj\$1name*, et *repo\$1name* par votre nom CodeCatalyst d'utilisateur, le nom de l'espace, le nom du projet et le nom du référentiel de packages.
```
curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/1.0/my-app-1.0.jar \
--user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @target/path/to/my-app-1.0.jar
```
1. Utilisez la `curl` commande suivante pour publier le POM dans un CodeCatalyst référentiel. Remplacez*username*, *space\$1name**proj\$1name*, et *repo\$1name* par votre nom CodeCatalyst d'utilisateur, le nom de l'espace, le nom du projet et le nom du référentiel de packages.
```
curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/1.0/my-app-1.0.pom \
--user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @target/my-app-1.0.pom
```
1. À ce stade, le package Maven sera dans votre CodeCatalyst dépôt avec un statut de`Unfinished`. Pour pouvoir consommer le package, celui-ci doit être en bon `Published` état. Vous pouvez déplacer le package de `Unfinished` à `Published` en téléchargeant un `maven-metadata.xml` fichier dans votre package ou en modifiant le statut dans la CodeCatalyst console.
1. Option 1 : utilisez la `curl` commande suivante pour ajouter un `maven-metadata.xml` fichier à votre package. Remplacez*username*, *space\$1name**proj\$1name*, et *repo\$1name* par votre nom CodeCatalyst d'utilisateur, le nom de l'espace, le nom du projet et le nom du référentiel de packages.
```
curl --request PUT https://packages.region.codecatalyst.aws/maven/space-name/proj-name/repo-name/com/mycompany/app/my-app/maven-metadata.xml \
--user "username:CodeCatalyst_ARTIFACTS_TOKEN" --header "Content-Type: application/octet-stream" \
--data-binary @target/maven-metadata.xml
```
Voici un exemple du contenu d'un `maven-metadata.xml` fichier :
```
com.mycompany.app
my-app
1.0
1.0
1.0
20200731090423
```
1. Option 2 : mettez à jour le statut du package sur la CodeCatalyst console. `Published` Pour plus d'informations sur la façon de mettre à jour le statut d'une version de package, consultez[Mettre à jour le statut d'une version de package](working-with-packages-update-version-status.md).
Si vous ne disposez que du fichier JAR d'un package, vous pouvez publier une version de package consommable dans un CodeCatalyst référentiel à l'aide `mvn` de. Cela peut être utile si vous n'avez pas accès au code source ou au POM du package. Consultez [Publication de packages tiers](packages-maven-mvn.md#publishing-third-party-packages) pour plus de détails.
# Utilisation des checksums et des instantanés Maven
Les sections suivantes décrivent comment utiliser les checksums Maven et les instantanés Maven dans. CodeCatalyst
## Utilisation des checksums Maven
Lorsqu'un package Maven est publié dans un référentiel de CodeCatalyst packages, la somme de contrôle associée à chaque *actif* ou fichier du package est utilisée pour valider le téléchargement. Les fichiers *jar*, *pom* et *war* sont des exemples d'actifs. Pour chaque ressource, le package Maven contient plusieurs fichiers checksum qui utilisent le nom de la ressource avec une extension supplémentaire, telle que `md5` ou. `sha1` Par exemple, les fichiers de somme de contrôle d'un fichier nommé `my-maven-package.jar` peuvent être `my-maven-package.jar.md5` et`my-maven-package.jar.sha1`.
Chaque package Maven contient également un `maven-metadata.xml` fichier. Ce fichier doit être chargé pour qu'une publication réussisse. Si une incompatibilité de somme de contrôle est détectée lors du téléchargement d'un fichier de package, la publication s'arrête. Cela pourrait `maven-metadata.xml` empêcher le téléchargement. Lorsque cela se produit, le statut du package Maven est défini sur. `Unfinished` Vous ne pouvez pas télécharger les ressources qui font partie d'un package présentant ce statut.
Tenez compte des points suivants en cas de divergence de somme de contrôle lorsque vous publiez un package Maven :
+ Si la somme de contrôle ne correspond pas avant `maven-metadata.xml` le téléchargement, le statut du package n'est pas défini sur. `Unfinished` Le package n'est pas visible et ses actifs ne peuvent pas être consommés. Dans ce cas, essayez l'une des solutions suivantes, puis réessayez de télécharger la ressource.
+ Exécutez à nouveau la commande qui publie le package Maven. Cela peut fonctionner si un problème réseau a endommagé le fichier checksum pendant le téléchargement. Si le problème réseau est résolu lors de la nouvelle tentative, la somme de contrôle correspond et le téléchargement est réussi.
+ Si la republication du package Maven ne fonctionne pas, supprimez-le, puis republiez-le.
+ Si la somme de contrôle ne correspond pas après `maven-metadata.xml` le téléchargement, le statut du package est défini sur. `Published` Vous pouvez consommer n'importe quel actif du package, y compris ceux présentant des incohérences entre les checksum. Lorsque vous téléchargez un actif, le checksum généré par CodeCatalyst est téléchargé avec celui-ci. Si le fichier téléchargé est associé à une incompatibilité de somme de contrôle, le fichier de somme de contrôle téléchargé risque de ne pas correspondre à la somme de contrôle chargée lors de la publication du package.
## Utilisation des instantanés Maven
Un *instantané* Maven est une version spéciale d'un package Maven qui fait référence au dernier code de branche de production. Il s'agit d'une version de développement qui précède la version finale. Vous pouvez identifier une version instantanée d'un package Maven à l'aide du suffixe `SNAPSHOT` ajouté à la version du package. Par exemple, l'instantané de la version `1.1` est`1.1-SNAPSHOT`. Pour plus d'informations, voir [Qu'est-ce qu'une version SNAPSHOT ?](https://maven.apache.org/guides/getting-started/index.html#What_is_a_SNAPSHOT_version) sur le site Web du projet Apache Maven.
CodeCatalyst prend en charge la publication et la consommation d'instantanés Maven. Vous pouvez publier un instantané Maven dans un CodeCatalyst référentiel ou, si vous êtes directement connecté, dans un référentiel en amont. Cependant, une version instantanée dans un référentiel de packages et dans l'un de ses référentiels en amont n'est pas prise en charge. Par exemple, si vous téléchargez un package Maven avec une version dans votre référentiel `1.2-SNAPSHOT` de packages, CodeCatalyst cela ne prend pas en charge le téléchargement d'un package Maven avec la même version instantanée vers l'un de ses référentiels en amont. Ce scénario peut donner des résultats imprévisibles.
Lorsqu'un instantané Maven est publié, sa version précédente est conservée dans une nouvelle version appelée *build*. Chaque fois qu'un instantané Maven est publié, une nouvelle version de build est créée. Toutes les versions précédentes d'un instantané sont conservées dans ses versions de compilation. Lorsqu'un instantané Maven est publié, son statut est défini sur `Published` et le statut de la version contenant la version précédente est défini sur. `Unlisted`
Si vous demandez un instantané, la version avec le statut `Published` est renvoyée. Il s'agit toujours de la version la plus récente de l'instantané Maven. Vous pouvez également demander une version particulière d'un instantané.
Pour supprimer toutes les versions de build d'un instantané Maven, utilisez la CodeCatalyst console.
# En utilisant NuGet
Ces rubriques décrivent comment consommer et publier des `NuGet` packages à l'aide de CodeCatalyst.
**Note**
CodeCatalyst prend en charge les [NuGetversions 4.8](https://docs.microsoft.com/en-us/nuget/release-notes/nuget-4.8-rtm) et supérieures.
**Topics**
+ [Utilisation CodeCatalyst avec Visual Studio](packages-nuget-visual-studio.md)
+ [Configuration et utilisation de la CLI nuget ou dotnet](packages-nuget-cli.md)
+ [NuGet normalisation du nom du package, de la version et du nom des actifs](nuget-name-normalization.md)
+ [NuGet compatibilité](packages-nuget-compatibility.md)
# Utilisation CodeCatalyst avec Visual Studio
Vous pouvez utiliser des packages CodeCatalyst directement depuis Visual Studio.
Pour configurer et utiliser NuGet avec des outils CLI tels que `dotnet` ou`nuget`, voir[Configuration et utilisation de la CLI nuget ou dotnet](packages-nuget-cli.md).
**Contents**
+ [Configuration de Visual Studio avec CodeCatalyst](#packages-nuget-vs-configure)
+ [Windows](#packages-nuget-vs-configure-windows)
+ [macOS](#packages-nuget-vs-configure-mac)
## Configuration de Visual Studio avec CodeCatalyst
### Windows
**Pour configurer Visual Studio avec CodeCatalyst**
1. Un jeton d'accès personnel (PAT) est nécessaire pour s'authentifier. CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Si ce n'est pas le cas, suivez les instructions [Accorder aux utilisateurs l'accès au référentiel avec des jetons d'accès personnels](ipa-tokens-keys.md) pour en créer un.
1. Utilisez `nuget` ou `dotnet` pour configurer votre référentiel de packages et vos informations d'identification.
------
#### [ dotnet ]
**Utilisateurs de Linux et de macOS :** le chiffrement n'étant pas pris en charge sur les plateformes autres que Windows, vous devez ajouter l'`--store-password-in-clear-text`indicateur à la commande suivante. Notez que cela enregistrera votre mot de passe sous forme de texte brut dans votre fichier de configuration.
```
dotnet nuget add source https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/v3/index.json --name repo_name --password PAT --username user_name
```
------
#### [ nuget ]
```
nuget sources add -name repo_name -Source https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/v3/index.json -password PAT --username user_name
```
------
Exemple de sortie :
```
Package source with Name: repo_name added successfully.
```
1. Configurez Visual Studio pour utiliser votre nouvelle source de package. Dans Visual Studio, choisissez **Outils**, puis **Options**.
1. Dans le menu **Options**, développez la section **NuGet Package Manager** et choisissez **Package Sources**.
1. Dans la liste des **sources de packages disponibles**, assurez-vous que votre *repo\$1name* source est activée. Si vous avez configuré votre dépôt de packages avec une connexion en amont à la NuGet galerie, désactivez le code source **nuget.org**.
### macOS
**Pour configurer Visual Studio avec CodeCatalyst**
1. Un jeton d'accès personnel (PAT) est nécessaire pour s'authentifier. CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Si ce n'est pas le cas, suivez les instructions [Accorder aux utilisateurs l'accès au référentiel avec des jetons d'accès personnels](ipa-tokens-keys.md) pour en créer un.
1. Choisissez **Préférences** dans la barre de menu.
1. Dans la **NuGet**section, sélectionnez **Sources**.
1. Choisissez **Ajouter** et ajoutez les informations de votre référentiel.
1. Dans **Nom**, entrez le nom de votre référentiel de CodeCatalyst packages.
1. Dans **Emplacement**, entrez le point de terminaison de votre référentiel de CodeCatalyst packages. L'extrait suivant montre un exemple de point de terminaison. Remplacez *space-name**proj-name*, et *repo-name* par le nom de votre CodeCatalyst espace, le nom du projet et le nom du référentiel.
```
https://packages.region.codecatalyst.aws/nuget/space-name/proj-name/repo-name/
```
1. Pour **Nom d'utilisateur**, entrez une valeur valide.
1. Dans le **champ Mot de passe**, entrez votre PAT.
1. Choisissez **Add source (Ajouter une source)**.
1. Si vous avez configuré votre dépôt de packages avec une connexion en amont à la NuGet galerie, désactivez le code source **nuget.org**.
Après la configuration, Visual Studio peut consommer des packages provenant de votre CodeCatalyst référentiel, de n'importe lequel de ses référentiels en amont ou de [NuGet.org](https://www.nuget.org/) si vous l'avez configuré en tant que source en amont. Pour plus d'informations sur la navigation et l'installation de NuGet packages dans Visual Studio, voir [Installer et gérer des packages dans Visual Studio à l'aide NuGet du gestionnaire](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-visual-studio) de packages dans la *NuGet documentation*.
# Configuration et utilisation de la CLI nuget ou dotnet
Vous pouvez utiliser des outils CLI tels que `NuGet` et `dotnet` pour publier et consommer des packages à partir de CodeCatalyst. Ce document fournit des informations sur la configuration des outils CLI et leur utilisation pour publier ou consommer des packages.
**Contents**
+ [Configuration NuGet avec CodeCatalyst](#nuget-configure-cli)
+ [Consommation de NuGet packages à partir d'un CodeCatalyst référentiel](#nuget-consume-cli)
+ [Consommer NuGet des packages depuis NuGet .org via CodeCatalyst](#nuget-consume-nuget-gallery)
+ [Publier NuGet des packages vers CodeCatalyst](#nuget-publish-cli)
## Configuration NuGet avec CodeCatalyst
Pour configurer NuGet avec CodeCatalyst, ajoutez un point de terminaison de référentiel et un jeton d'accès personnel à votre fichier de NuGet configuration pour autoriser `nuget` ou `dotnet` pour vous connecter à votre référentiel de CodeCatalyst packages.
**Pour configurer NuGet avec votre référentiel de CodeCatalyst packages**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Sur la page d'aperçu de votre projet, sélectionnez **Packages**.
1. Choisissez votre référentiel de packages dans la liste des référentiels de packages.
1. Choisissez **Connect to repository**.
1. Dans la boîte de dialogue **Connect to repository**, choisissez **NuGet**ou **dotnet** dans la liste des clients du gestionnaire de packages.
1. Vous aurez besoin d'un jeton d'accès personnel (PAT) pour vous authentifier. NuGet CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Si ce n'est pas le cas, vous pouvez en créer un ici.
1. Choisissez **Créer un jeton**.
1. Choisissez **Copier** pour copier votre PAT.
**Avertissement**
Vous ne pourrez plus voir ou copier votre PAT une fois que vous aurez fermé la boîte de dialogue.
1. Configurez `nuget` ou utilisez `dotnet` le NuGet point de terminaison et le CodeCatalyst PAT de votre référentiel. Remplacez les valeurs suivantes.
**Note**
Si vous copiez les instructions depuis la console, les valeurs suivantes doivent être mises à jour pour vous et ne doivent pas être modifiées.
+ Remplacez *username* par votre nom CodeCatalyst d'utilisateur.
+ *PAT*Remplacez-le par votre CodeCatalyst PAT.
+ Remplacez *space\$1name* par le nom de votre CodeCatalyst espace.
+ Remplacez *proj\$1name* par le nom CodeCatalyst de votre projet.
+ *repo\$1name*Remplacez-le par le nom CodeCatalyst du dépôt de votre package.
1. Pour `nuget`, utilisez la commande `nuget sources add`.
```
nuget sources add -name "repo_name" -Source "https://packages.region.codecatalyst.aws/nuget/space_name/proj_name/repo_name/v3/index.json" -username "username" -password "PAT"
```
1. Pour `dotnet`, utilisez la commande `dotnet nuget add source`.
**Utilisateurs de Linux et de macOS** : le chiffrement n'étant pas pris en charge sur les plateformes autres que Windows, vous devez ajouter l'`--store-password-in-clear-text`indicateur à la commande suivante. Notez que cela enregistrera votre mot de passe sous forme de texte brut dans votre fichier de configuration.
```
dotnet nuget add source "https://packages.region.codecatalyst.aws/nuget/space_name/proj_name/repo_name/v3/index.json" -n "proj_name/repo_name" -u "username" -p "PAT" --store-password-in-clear-text
```
Une fois que vous avez configuré NuGet avec CodeCatalyst, vous pouvez [utiliser des NuGet packages](#nuget-consume-cli) stockés dans votre CodeCatalyst référentiel ou dans l'un de ses référentiels en amont et [publier des NuGet packages](#nuget-publish-cli) dans votre CodeCatalyst référentiel.
## Consommation de NuGet packages à partir d'un CodeCatalyst référentiel
Une fois que vous avez [configuré NuGet avec CodeCatalyst](#nuget-configure-cli), vous pouvez utiliser les NuGet packages stockés dans votre CodeCatalyst référentiel ou dans l'un de ses référentiels en amont.
Pour utiliser une version de package depuis un CodeCatalyst référentiel ou l'un de ses référentiels en amont avec nuget ou dotnet, exécutez la commande suivante. Remplacez-le *packageName* par le nom du package que vous souhaitez consommer et *packageSourceName* par le nom de la source de votre référentiel de CodeCatalyst packages dans votre fichier de NuGet configuration, qui doit être le nom du référentiel.
**Pour installer un package avec `dotnet`**
```
dotnet add packageName --source packageSourceName
```
**Pour installer un package avec `nuget`**
```
nuget install packageName --source packageSourceName
```
Pour plus d'informations, voir [Gérer les packages à l'aide de la CLI nuget](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-nuget-cli) ou [Installer et gérer les packages à l'aide de la CLI dotnet](https://docs.microsoft.com/en-us/nuget/consume-packages/install-use-packages-dotnet-cli) dans la documentation *Microsoft*.
## Consommer NuGet des packages depuis NuGet .org via CodeCatalyst
Vous pouvez utiliser des NuGet packages provenant de [NuGet.org](https://www.nuget.org/) via un CodeCatalyst référentiel en configurant le référentiel avec une connexion en amont à **NuGet.org**. Les paquets consommés depuis **NuGet.org** sont ingérés et stockés dans votre CodeCatalyst dépôt.
**Pour consommer des packages provenant de NuGet .org**
1. Si ce n'est pas déjà fait, configurez votre gestionnaire de NuGet packages avec votre référentiel de CodeCatalyst packages en suivant les étapes décrites dans[Configuration NuGet avec CodeCatalyst](#nuget-configure-cli).
1. Assurez-vous que votre dépôt a ajouté **NuGet.org** en tant que connexion en amont. Vous pouvez vérifier quelles sources en amont sont ajoutées ou ajouter **Nuget.org** en tant que source en amont en suivant les instructions [Ajout d’un référentiel en amont](packages-upstream-repositories-add.md) et en choisissant le référentiel du **NuGet magasin**.
## Publier NuGet des packages vers CodeCatalyst
Une fois que vous avez [configuré NuGet avec CodeCatalyst](#nuget-configure-cli), vous pouvez utiliser `nuget` ou `dotnet` publier des versions de package dans CodeCatalyst des référentiels.
Pour transférer une version de package vers un CodeCatalyst référentiel, exécutez la commande suivante en indiquant le chemin complet de votre `.nupkg` fichier et le nom de la source de votre CodeCatalyst référentiel dans votre fichier NuGet de configuration.
**Pour publier un package avec `dotnet`**
```
dotnet nuget push path/to/nupkg/SamplePackage.1.0.0.nupkg --source packageSourceName
```
**Pour publier un package avec `nuget`**
```
nuget push path/to/nupkg/SamplePackage.1.0.0.nupkg --source packageSourceName
```
# NuGet normalisation du nom du package, de la version et du nom des actifs
CodeCatalyst normalise les noms des packages et des actifs ainsi que les versions des packages avant de les stocker, ce qui signifie que les noms ou les versions CodeCatalyst peuvent être différents de ceux fournis lors de la publication du package ou de l'actif.
**Normalisation des noms de packages :** CodeCatalyst normalise les noms de NuGet packages en convertissant toutes les lettres en minuscules.
**Normalisation des versions des packages :** CodeCatalyst normalise les versions des NuGet packages en utilisant le même modèle que NuGet. Les informations suivantes proviennent des [numéros de version normalisés](https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#normalized-version-numbers) de la NuGet documentation.
+ Les zéros principaux sont supprimés des numéros de version :
+ `1.00`est traité comme `1.0`
+ `1.01.1`est traité comme `1.1.1`
+ `1.00.0.1`est traité comme `1.0.0.1`
+ Un zéro dans la quatrième partie du numéro de version sera omis :
+ `1.0.0.0`est traité comme `1.0.0`
+ `1.0.01.0`est traité comme `1.0.1`
+ SemVer Les métadonnées de build 2.0.0 sont supprimées :
+ `1.0.7+r3456`est traité comme `1.0.7`
**Normalisation du nom du package :** CodeCatalyst construit le nom du NuGet package à partir du nom du package normalisé et de la version du package.
# NuGet compatibilité
Ce guide contient des informations sur CodeCatalyst la compatibilité avec différents NuGet outils et versions.
**Topics**
+ [NuGet Compatibilité générale](#nuget-version-support)
+ [NuGet support en ligne de commande](#nuget-command-line-support)
## NuGet Compatibilité générale
CodeCatalyst prend en charge les versions NuGet 4.8 et supérieures.
CodeCatalyst supporte uniquement la version 3 du protocole NuGet HTTP. Cela signifie que certaines commandes CLI qui reposent sur la version 2 du protocole ne sont pas prises en charge. Consultez la [support des commandes nuget](#nuget-command-support) section suivante pour plus d'informations.
CodeCatalyst ne prend pas en charge la version PowerShellGet 2.x.
## NuGet support en ligne de commande
CodeCatalyst prend en charge les outils CLI NuGet (`nuget``dotnet`) et .NET Core ().
### support des commandes nuget
Comme elle CodeCatalyst ne prend en charge que le protocole HTTP NuGet de la version 3 de, les commandes suivantes ne fonctionneront pas lorsqu'elles sont utilisées avec des CodeCatalyst ressources :
+ `list`: La `nuget list` commande affiche une liste de packages provenant d'une source donnée. Pour obtenir la liste des packages d'un référentiel de CodeCatalyst packages, accédez au référentiel dans la CodeCatalyst console.
# Utilisation de Python
Ces rubriques décrivent comment utiliser `pip` le gestionnaire de packages Python et `twine` l'utilitaire de publication de packages Python avec CodeCatalyst.
**Topics**
+ [Configuration de pip et installation de packages Python](packages-python-pip.md)
+ [Configuration de Twine et publication de packages Python](packages-python-twine.md)
+ [Normalisation du nom des paquets Python](python-name-normalization.md)
+ [Compatibilité Python](packages-python-compatibility.md)
# Configuration de pip et installation de packages Python
Pour l'utiliser `pip` avec CodeCatalyst, vous devez vous connecter `pip` à votre référentiel de packages et fournir un jeton d'accès personnel pour l'authentification. Vous pouvez consulter les instructions de connexion `pip` à votre référentiel de packages dans la CodeCatalyst console. Après vous être authentifié et `pip` connecté CodeCatalyst, vous pouvez exécuter des `pip` commandes.
**Contents**
+ [Installation de packages Python à partir CodeCatalyst de pip](#pip-install)
+ [Consommation de packages Python depuis PyPI jusqu'à CodeCatalyst](#pip-install-pypi)
+ [support de la commande pip](#pip-command-support)
+ [Commandes prises en charge qui interagissent avec un référentiel](#supported-pip-commands-that-interact-with-a-repository)
+ [Commandes côté client prises en charge](#supported-pip-client-side-commands)
## Installation de packages Python à partir CodeCatalyst de pip
Les instructions suivantes expliquent comment configurer l'installation de packages Python `pip` à partir de votre CodeCatalyst référentiel de packages ou de l'un de ses référentiels en amont.
**À configurer et à utiliser `pip` pour installer des packages Python à partir de votre référentiel de CodeCatalyst packages**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Sur la page d'aperçu de votre projet, sélectionnez **Packages**.
1. Choisissez votre référentiel de packages dans la liste des référentiels de packages.
1. Choisissez **Connect to repository**.
1. Dans la boîte de dialogue **Connect to repository**, sélectionnez **pip** dans la liste des clients du gestionnaire de packages.
1. Vous aurez besoin d'un jeton d'accès personnel (PAT) pour authentifier pip. CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Si ce n'est pas le cas, vous pouvez en créer un ici.
1. Choisissez **Créer un jeton**.
1. Choisissez **Copier** pour copier votre PAT.
**Avertissement**
Vous ne pourrez plus voir ou copier votre PAT une fois que vous aurez fermé la boîte de dialogue.
1. Utilisez la `pip config` commande pour définir l'URL du CodeCatalyst registre et les informations d'identification. Remplacez les valeurs suivantes.
**Note**
Si vous copiez les instructions depuis la console, les valeurs suivantes doivent être mises à jour pour vous et ne doivent pas être modifiées.
+ Remplacez *username* par votre nom CodeCatalyst d'utilisateur.
+ *PAT*Remplacez-le par votre CodeCatalyst PAT.
+ *space\$1name*Remplacez-le par le nom de votre CodeCatalyst espace.
+ Remplacez *proj\$1name* par le nom CodeCatalyst de votre projet.
+ *repo\$1name*Remplacez-le par le nom CodeCatalyst du dépôt de votre package.
```
pip config set global.index-url https://username:PAT@https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/simple/
```
1. En supposant qu'un package soit présent dans votre dépôt ou dans l'un de ses référentiels en amont, vous pouvez l'installer avec`pip install`. Par exemple, utilisez la commande suivante pour installer le `requests` package.
```
pip install requests
```
Utilisez `-i` cette option pour revenir temporairement à l'installation de packages depuis [https://pypi.org](https://pypi.org) au lieu de votre référentiel de CodeCatalyst packages.
```
pip install -i https://pypi.org/simple requests
```
## Consommation de packages Python depuis PyPI jusqu'à CodeCatalyst
**Vous pouvez utiliser des packages Python issus du [Python Package Index (PyPI](https://www.pypi.org/)) via CodeCatalyst un référentiel en configurant le référentiel avec une connexion en amont à PyPI.** Les packages consommés à partir de **PyPI** sont ingérés et stockés dans votre référentiel. CodeCatalyst
**Pour consommer des packages depuis PyPI**
1. Si ce n'est pas déjà fait, configurez pip avec votre référentiel de CodeCatalyst packages en suivant les étapes décrites dans[Installation de packages Python à partir CodeCatalyst de pip](#pip-install).
1. Assurez-vous que votre dépôt a ajouté **PyPI** en tant que source en amont. Vous pouvez vérifier quelles sources en amont sont ajoutées ou ajouter **PyPI** en tant que source en amont en suivant les instructions et [Ajout d’un référentiel en amont](packages-upstream-repositories-add.md) en choisissant le référentiel de stockage **PyPI**.
Pour plus d'informations sur la demande de packages à partir de référentiels en amont, consultez[Demande d'une version de package avec des référentiels en amont](packages-upstream-repositories-request.md).
## support de la commande pip
Les sections suivantes résument les commandes pip prises en charge par les CodeCatalyst référentiels, en plus des commandes spécifiques non prises en charge.
**Topics**
+ [Commandes prises en charge qui interagissent avec un référentiel](#supported-pip-commands-that-interact-with-a-repository)
+ [Commandes côté client prises en charge](#supported-pip-client-side-commands)
### Commandes prises en charge qui interagissent avec un référentiel
Cette section répertorie `pip` les commandes dans lesquelles le `pip` client envoie une ou plusieurs requêtes au registre avec lequel il a été configuré. Il a été vérifié que ces commandes fonctionnent correctement lorsqu'elles sont invoquées dans un référentiel de CodeCatalyst packages.
****
| Commande | Description |
| --- | --- |
| [installer](https://pip.pypa.io/en/stable/reference/pip_install/) | Installez les packages. |
| [télécharger](https://pip.pypa.io/en/stable/reference/pip_download/) | Téléchargez les packages. |
CodeCatalyst ne met pas en œuvre`pip search`. Si vous avez configuré `pip` avec un référentiel de CodeCatalyst packages, l'exécution `pip search` recherchera et affichera les packages depuis [PyPI](https://pypi.org/).
### Commandes côté client prises en charge
Ces commandes ne nécessitent aucune interaction directe avec un dépôt, il n'est donc CodeCatalyst pas nécessaire de faire quoi que ce soit pour les prendre en charge.
****
| Commande | Description |
| --- | --- |
| [désinstaller](https://pip.pypa.io/en/stable/reference/pip_uninstall/) | Désinstallez les packages. |
| [geler](https://pip.pypa.io/en/stable/reference/pip_freeze/) | Afficher les packages installés au format des exigences. |
| [liste](https://pip.pypa.io/en/stable/reference/pip_list/) | Répertoriez les packages installés. |
| [sh](https://pip.pypa.io/en/stable/reference/pip_show/)ow | Afficher les informations sur les packages installés. |
| [vérifier](https://pip.pypa.io/en/stable/reference/pip_check/) | Vérifiez que les packages installés ont des dépendances compatibles. |
| [configuration](https://pip.pypa.io/en/stable/reference/pip_config/) | Gérez la configuration locale et globale. |
| [roue](https://pip.pypa.io/en/stable/reference/pip_wheel/) | Construisez des roues selon vos besoins. |
| [hachage](https://pip.pypa.io/en/stable/reference/pip_hash/) | Calculez les hachages des archives de packages. |
| [achèvement](https://pip.pypa.io/en/stable/user_guide/#command-completion) | Facilite l'exécution des commandes. |
| [debug](https://pip.pypa.io/en/stable/reference/pip_debug/) | Afficher les informations utiles pour le débogage. |
| help | Afficher l'aide pour les commandes. |
# Configuration de Twine et publication de packages Python
Pour l'utiliser `twine` avec CodeCatalyst, vous devez vous connecter `twine` à votre référentiel de packages et fournir un jeton d'accès personnel pour l'authentification. Vous pouvez consulter les instructions de connexion `twine` à votre référentiel de packages dans la CodeCatalyst console. Après vous être authentifié et `twine` connecté CodeCatalyst, vous pouvez exécuter des `twine` commandes.
## Publier des packages vers CodeCatalyst avec Twine
Les instructions suivantes expliquent comment vous authentifier et vous connecter `twine` à votre référentiel de CodeCatalyst packages.
**À configurer et `twine` à utiliser pour publier des packages dans votre référentiel de CodeCatalyst packages**
1. Ouvrez la CodeCatalyst console à l'[adresse https://codecatalyst.aws/](https://codecatalyst.aws/).
1. Sur la page d'aperçu de votre projet, sélectionnez **Packages**.
1. Choisissez votre référentiel de packages dans la liste des référentiels de packages.
1. Choisissez **Connect to repository**.
1. Dans la boîte de dialogue **Connect to repository**, choisissez **Twine** dans la liste des clients du gestionnaire de packages.
1. Vous aurez besoin d'un jeton d'accès personnel (PAT) pour authentifier Twine. CodeCatalyst Si vous en avez déjà un, vous pouvez l'utiliser. Si ce n'est pas le cas, vous pouvez en créer un ici.
1. Choisissez **Créer un jeton**.
1. Choisissez **Copier** pour copier votre PAT.
**Avertissement**
Vous ne pourrez plus voir ou copier votre PAT une fois que vous aurez fermé la boîte de dialogue.
1. Vous pouvez configurer Twine à l'aide d'un `.pypirc` fichier ou de variables d'environnement.
1. **Pour configurer à l'aide d'un `.pypirc` fichier.**
Ouvrez `~/.pypirc` dans l'éditeur de votre choix.
Ajoutez un serveur d'index pour CodeCatalyst, y compris le référentiel, le nom d'utilisateur et le PAT que vous avez créés et copiés lors d'une étape précédente. Remplacez les valeurs suivantes.
**Note**
Si vous copiez les instructions depuis la console, les valeurs suivantes doivent être mises à jour pour vous et ne doivent pas être modifiées.
+ Remplacez *username* par votre nom CodeCatalyst d'utilisateur.
+ *PAT*Remplacez-le par votre CodeCatalyst PAT.
+ *space\$1name*Remplacez-le par le nom de votre CodeCatalyst espace.
+ Remplacez *proj\$1name* par le nom CodeCatalyst de votre projet.
+ *repo\$1name*Remplacez-le par le nom CodeCatalyst du dépôt de votre package.
```
[distutils]
index-servers = proj-name/repo-name
[proj-name/repo-name]
repository = https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/
password = PAT
username = username
```
1. **Pour configurer avec des variables d'environnement.**
Définissez les variables d'environnement suivantes. Dans la `TWINE_REPOSITORY_URL` valeur, la mise à jour *space\$1name**proj\$1name*, et *repo\$1name* avec les noms de vos référentiels d' CodeCatalyst espace, de projet et de package.
```
export TWINE_USERNAME=username
```
```
export TWINE_PASSWORD=PAT
```
```
export TWINE_REPOSITORY_URL="https://packages.region.codecatalyst.aws/pypi/space_name/proj_name/repo_name/"
```
1. Publiez une distribution Python à l'aide de la `twine upload` commande.
# Normalisation du nom des paquets Python
CodeCatalyst normalise les noms de package avant de les stocker, ce qui signifie que les noms de package CodeCatalyst peuvent être différents du nom fourni lors de la publication du package.
Pour les packages Python, lors de la normalisation, le nom du package est en minuscules et toutes les instances des caractères « `.``-`, » `_` sont remplacées par un seul caractère. `-` Ainsi, les noms des packages `pigeon.cli` sont normalisés `pigeon_cli` et stockés sous le nom `pigeon-cli` de. Le nom non normalisé peut être utilisé par pip et twine. Pour plus d'informations sur la normalisation des noms de paquets Python, consultez le [PEP 503](https://www.python.org/dev/peps/pep-0503/#normalized-names) dans la documentation Python.
# Compatibilité Python
Bien qu' CodeCatalyst il ne prenne pas en charge l'`/simple/`API, il prend en charge les opérations de l'`Legacy`API. CodeCatalyst ne prend pas en charge les opérations PyPI `XML-RPC` ou `JSON` API.
Pour plus d'informations, consultez ce qui suit sur le GitHub référentiel de la Python Packaging Authority.
+ [API héritée](https://warehouse.pypa.io/api-reference/legacy.html)
+ [API XML-RPC](https://github.com/pypi/warehouse/blob/main/docs/dev/api-reference/xml-rpc.rst)
+ [API JSON](https://docs.pypi.org/api/json/)
# Quotas pour les packages
Le tableau suivant décrit les quotas et les limites pour les packages sur Amazon CodeCatalyst. Pour plus d'informations sur les quotas sur Amazon CodeCatalyst, consultez[Quotas pour CodeCatalyst](quotas.md).
| Ressource | Quota par défaut |
| --- | --- |
| Référentiels de packages | Maximum de 1 000 par espace. |
| Référentiels en amont direct | Maximum de 10 par référentiel de packages. |
| Référentiels de packages recherchés en amont | Maximum de 25 référentiels en amont recherchés par version de package demandée. |
| Taille du fichier d'actifs du package | Maximum de 5 Go par actif du package. |
| Actifs du package | Maximum de 150 par version de package. |